# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-29T12:29:55Z", "synthesisSha256": "8596728327ccddb5d33db332dc4d72926bcd35ae70eeb0c93a68a226153f63ca", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-ACT-027", "registryId": "vr.wm-act-027", "name": "Communication Interaction", "version": "0.3.1-research.1", "previousVersions": [ { "version": "0.3.0-research.1", "url": "/models/wm-act-027-communication-interaction/versions/0.3.0-research.1/" } ], "entryKind": "aggregate", "family": "World Models", "category": "Activities and processes", "industry": [ "Cross-industry" ], "domain": [ "ACT.COM" ], "tags": [ "communication", "interaction", "act.com" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-act-027-communication-interaction/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-027", "model": { "registry_id": "vr.wm-act-027", "model_id": "WM-ACT-027", "name": "Communication Interaction", "entry_kind": "aggregate", "purpose": "Provide the format-neutral context an agent needs to open, conduct, evidence, classify, correlate and close a communication interaction - a bounded exchange of contact turns between identified parties across one or more channels - with its participant roster, channel and endpoint bindings, turn content, delivery evidence, lifecycle state, outcome and governance references.", "scope_statement": "WM-ACT-027 models the interaction record as an aggregate: an interaction root carrying identity, classification, participants-in-role, channel and endpoint bindings, ordered turns with content and attachments, threading relations, lifecycle and handling state, temporal points and windows, delivery and engagement evidence, outcome/disposition, and typed references to the party, permission, access, retention and audit models that own their own semantics. It stops at transport protocols, party master data, permission evaluation, policy enforcement, audit-trail production and disposition execution. It is storage- and interface-neutral: JSON, YAML, Markdown, HTML, Git, MCP and MongoDB are projections of these semantics, not their definition.", "in_scope": [ "The interaction as a unit of account: what opens one, what continues it across a channel switch, what closes it", "Interaction identity, correlation keys and cross-channel identifier resolution", "Participants in roles (initiator, addressee, copied, observer, handler) as references into an external party model", "Channel classification, channel capability constraints, and endpoint/address bindings including proxy-address pairs", "Direction (inbound, outbound, internal) and initiation attribution", "Ordered turns with authorship, sequence, content references and attachments", "Threading, reply and relation structure between turns and between interactions", "Lifecycle and handling state, assignment of handling responsibility, and state-change reasons", "Interaction time points, periods and channel engagement windows/timers", "Delivery, receipt, read and engagement evidence attached to turns", "Capture provenance: which system observed or authored the record and how faithfully", "Outcome, resolution and wrap-up disposition of the interaction", "Confidentiality/visibility classification and redaction markers carried on the record", "References to permission basis, retention class, access policy and audit records owned by sibling models", "Alignment bindings to external interaction schemas and vocabularies" ], "out_of_scope": [ "Party, organisation and person master data and their identity lifecycle (owned by the party model)", "The canonical contact-point/electronic-address registry and address verification", "Permission and consent capture, evaluation and withdrawal semantics (this model carries only a reference to the decision)", "Runtime access-control evaluation and enforcement (this model carries classification markers only)", "Audit-trail creation, immutability guarantees and audit query semantics", "Execution of deletion, anonymisation or disposition (this model carries the class and a tombstone marker only)", "Transport and signalling protocol behaviour (SIP/IMS sessions, SMTP relay, SMS submission, charging/CDR production)", "Case, ticket, order or service-request lifecycle (referenced, not reproduced)", "Campaign, journey and outbound orchestration logic", "Bot/NLU intent model training, ranking and dialogue policy", "Media file storage, transcoding and CDN delivery", "Workforce management, agent scheduling and staffing forecasts", "Billing, rating and settlement for communication traffic" ], "boundary_notes": [ { "neighbor": "Party / party-role model (e.g. TM Forum TMF632/TMF669 pattern)", "distinction": "TMF683 carries only relatedParty references with a role; the interaction record must not restate party attributes, party identity resolution or party lifecycle.", "source_refs": [ "SRC-001" ] }, { "neighbor": "Permission / consent model", "distinction": "ePrivacy and 47 CFR 64.1200 place consent capture, validity and revocation with the permission holder; this model records only the reference to a permission decision that was in force at send time, never the evaluation.", "source_refs": [ "SRC-007", "SRC-008" ] }, { "neighbor": "Clinical or business request model (FHIR CommunicationRequest)", "distinction": "FHIR separates the planned/ordered communication from the record of one that occurred; WM-ACT-027 covers the occurrence, with the request kept as a basedOn reference.", "source_refs": [ "SRC-002" ] }, { "neighbor": "Audit / disclosure log (FHIR AuditEvent pattern)", "distinction": "FHIR explicitly distinguishes Communication from AuditEvent; system-level disclosure tracking and audit-trail semantics stay in the audit model.", "source_refs": [ "SRC-002" ] }, { "neighbor": "Transport and protocol layer (RFC 5322 trace fields, Matrix federation, carrier submission)", "distinction": "Trace/Received fields and protocol event graphs are informational transport artefacts; this model consumes their identifiers and status outcomes without owning routing or delivery mechanics.", "source_refs": [ "SRC-005", "SRC-009" ] }, { "neighbor": "Records retention and disposition model", "distinction": "Sector rules such as MiFID II impose fixed retention on communication records, but the retention schedule and its execution belong to the retention model; this record only binds a retention class and a disposition marker.", "source_refs": [ "SRC-011", "SRC-013" ] }, { "neighbor": "Content / media asset model", "distinction": "Attachment bytes, transcoding and storage location are owned by the content model; this model carries attachment references, media type and integrity digests.", "source_refs": [ "SRC-001", "SRC-004" ] } ] }, "sources": [ { "id": "SRC-001", "title": "TMF683 Party Interaction API, OpenAPI (Swagger) definition v4.0.0", "organization": "TM Forum", "url": "https://raw.githubusercontent.com/tmforum-apis/TMF683_PartyInteraction/main/TMF683-PartyInteraction-v4.0.0.swagger.json", "version_or_date": "v4.0.0, Release 19.5, October 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:05:00Z", "relevance": "Normative resource model for a cross-channel party interaction: id, creationDate, description, direction, reason, status (opened/inProgress/completed), statusChangeDate, channel, interactionDate, interactionItem, note, relatedParty, attachment, interactionRelationship, plus create/update/delete/status-change event types." }, { "id": "SRC-002", "title": "FHIR R5 Communication Resource", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/communication.html", "version_or_date": "FHIR R5 (v5.0.0), Trial Use, maturity level 2", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:07:00Z", "relevance": "Record of a completed or attempted information transfer: identifier, basedOn, partOf, inResponseTo, status (EventStatus), statusReason, category, priority, medium, subject, topic, about, encounter, sent, received, sender, recipient, reason, payload, note; and explicit boundary statements against CommunicationRequest, AuditEvent, Flag and Encounter." }, { "id": "SRC-003", "title": "Activity Streams 2.0 Vocabulary", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/activitystreams-vocabulary/", "version_or_date": "W3C Recommendation, 23 May 2017", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:09:00Z", "relevance": "Actor/object/target/origin/result/instrument activity structure, audience targeting via to/cc/bto/bcc with the normative requirement that intermediaries remove bto/bcc, and object properties id, type, published, updated, inReplyTo, context, attributedTo, mediaType, attachment, replies." }, { "id": "SRC-004", "title": "RFC 8621: The JSON Meta Application Protocol (JMAP) for Mail", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc8621.html", "version_or_date": "Standards Track, August 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:11:00Z", "relevance": "Thread as a flat date-ordered list of Emails with explicit membership rules derived from Message-ID/In-Reply-To/References plus subject normalisation; keywords $seen/$draft/$answered/$flagged; receivedAt versus sentAt; bodyStructure/textBody/htmlBody/attachments; EmailSubmission for send-side state." }, { "id": "SRC-005", "title": "Matrix Client-Server API specification", "organization": "The Matrix.org Foundation C.I.C.", "url": "https://spec.matrix.org/latest/client-server-api/", "version_or_date": "v1.19 (latest at access date)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:14:00Z", "relevance": "Room and event model with room IDs/aliases, event IDs, m.room.message and m.room.member, membership states invite/join/leave/ban/knock, m.thread and m.in_reply_to relations, read receipts, typing notifications, redaction, history visibility and end-to-end encryption." }, { "id": "SRC-006", "title": "Message - Schema.org Type", "organization": "Schema.org (W3C Schema.org Community Group)", "url": "https://schema.org/Message", "version_or_date": "Schema.org V30.0, 2026-03-19", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:16:00Z", "relevance": "Widely deployed lightweight vocabulary for a single message: sender, recipient, toRecipient, ccRecipient, bccRecipient, dateSent, dateReceived, dateRead, messageAttachment, about; with EmailMessage and Conversation as related types." }, { "id": "SRC-007", "title": "Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector (ePrivacy Directive)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32002L0058", "version_or_date": "12 July 2002, OJ L 201, 31.7.2002, p. 37", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:19:00Z", "relevance": "Article 13 requires prior consent for automated calling, fax and electronic mail used for direct marketing, permits a soft opt-in for similar products with an easy free objection route in every message, and prohibits concealing sender identity or omitting a valid opt-out address." }, { "id": "SRC-008", "title": "47 CFR 64.1200 - Delivery restrictions", "organization": "Legal Information Institute, Cornell Law School (reproducing US Code of Federal Regulations, FCC)", "url": "https://www.law.cornell.edu/cfr/text/47/64.1200", "version_or_date": "Current CFR text as accessed 2026-08-29", "source_type": "legislation", "primary_source": false, "authority_tier": 2, "accessed_at": "2026-08-29T09:22:00Z", "relevance": "Prior express versus prior express written consent for autodialled/prerecorded calls and texts, company-specific and national do-not-call obligations, caller identification at message start, automated opt-out mechanism within two seconds, 8 a.m.-9 p.m. local calling window, 5-year honouring of do-not-call requests and 10-business-day handling of revocation including STOP/unsubscribe replies." }, { "id": "SRC-009", "title": "RFC 5322: Internet Message Format", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5322.html", "version_or_date": "Standards Track, October 2008", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:25:00Z", "relevance": "Globally unique Message-ID whose uniqueness is guaranteed by the generating host, In-Reply-To and References threading chains, originator fields From/Sender/Reply-To, destination fields To/Cc/Bcc, the Date field as author-declared completion time rather than transmission time, and informational trace fields." }, { "id": "SRC-010", "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": "Standards Track, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:27:00Z", "relevance": "Normative timestamp profile requiring full date-time with seconds and an explicit time-offset of Z or +/-hh:mm, allowance of second value 60 for leap seconds, and the -00:00 convention signalling that the local offset is unknown." }, { "id": "SRC-011", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation), consolidated text", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504", "version_or_date": "27 April 2016, consolidated 04 May 2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:30:00Z", "relevance": "Article 5 storage limitation and purpose limitation, Article 6 lawful basis, Article 7 demonstrable consent and easy withdrawal, Article 17 erasure when data are no longer necessary or consent is withdrawn, Article 21 objection to direct marketing, and Article 30 records of processing including envisaged erasure time limits." }, { "id": "SRC-012", "title": "WhatsApp Business Platform Cloud API - Send Messages", "organization": "Meta Platforms, Inc.", "url": "https://developers.facebook.com/docs/whatsapp/cloud-api/guides/send-messages", "version_or_date": "Cloud API developer documentation as accessed 2026-08-29", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-29T09:33:00Z", "relevance": "Concrete channel-capability constraints: a 24-hour customer service window opened and reset by user contact, free-form service messages only inside that window versus pre-approved template categories outside it, mandatory opt-in, a returned message ID that does not imply delivery, and sent/delivered/read/failed status webhooks with message TTL." }, { "id": "SRC-013", "title": "Commission Delegated Regulation (EU) 2017/565 supplementing Directive 2014/65/EU as regards organisational requirements and operating conditions for investment firms", "organization": "European Commission", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R0565", "version_or_date": "25 April 2016, OJ L 87, 31.3.2017, p. 1", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:36:00Z", "relevance": "Sector record-keeping regime for communications: recital 92 ties record-keeping to supervisory tasks and requires records proportionate to the services performed, and Articles 72-76 govern retention of records including recording of telephone conversations and electronic communications on a durable medium." } ], "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Interaction Definition, Identity and Classification", "description": "Establishes what one Communication Interaction record is, how it is typed, and how it is identified and correlated across channels and systems.", "rationale": "Every downstream concern - threading, evidence, retention - depends on a stable unit of account and a resolvable identifier. TMF683 and FHIR both make identity and category first-class, and RFC 5322/JMAP show that threading itself is computed from identifiers.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-009" ], "layers": [ { "id": "subject-definition-and-boundary", "name": "Subject Definition and Boundary", "description": "The bounded exchange that a single interaction record represents, and its classification vocabulary.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "findings": [ { "id": "interaction-unit-of-account", "name": "Interaction Unit of Account", "description": "The rule set determining what constitutes one interaction record: which exchange is enclosed, when a channel switch or idle gap starts a new record, and whether the record is a container of turns or a single atomic transfer.", "source_refs": [ "SRC-001", "SRC-002", "SRC-012" ], "questions": [ { "id": "q-unit-boundary", "text": "What exchange boundary does a single communication interaction record enclose?", "kind": "definition", "answer_data": [ "Interaction scope rule statement", "Container-versus-atomic granularity code", "Worked examples of one record versus many" ] }, { "id": "q-unit-channel-switch", "text": "When does a channel switch continue the existing interaction rather than open a new one?", "kind": "decision", "answer_data": [ "Channel-switch continuation policy", "Correlation key that must match for continuation", "Whether the prior channel binding is retained or superseded" ] }, { "id": "q-unit-idle-close", "text": "Which idle interval or closure event terminates an interaction for record-keeping purposes?", "kind": "constraint", "answer_data": [ "Inactivity duration threshold per channel", "Explicit closure event types", "Behaviour when a party replies after closure" ] }, { "id": "q-unit-attempted", "text": "Is an attempted but unconnected contact recorded as an interaction?", "kind": "exception", "answer_data": [ "Attempt-recording policy", "Status value used for non-completed transfers", "Minimum data required for an attempt record" ] } ], "data_elements": [ { "id": "de-interaction-scope-rule", "name": "Interaction Scope Rule", "description": "Declared rule that defines the enclosed exchange for this interaction population.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-continuation-window", "name": "Continuation Window", "description": "Maximum inactivity duration after which a further contact opens a new interaction rather than continuing this one.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-granularity-code", "name": "Granularity Code", "description": "Whether the record is a turn-container aggregate or a single atomic transfer.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "This finding is definitional policy expressed as structured rule and threshold values on the interaction population; it produces no document, media object or transmissible file of its own and is consumed directly as inline reference data by the open-interaction and append-turn functions." }, { "id": "interaction-classification-scheme", "name": "Interaction Classification Scheme", "description": "The typing dimensions carried on the interaction - purpose/reason, business category, priority, medium and activity verb - and the controlled vocabularies bound to each.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-006" ], "questions": [ { "id": "q-class-dimensions", "text": "Which independent classification dimensions does the interaction carry?", "kind": "classification", "answer_data": [ "Dimension list with cardinality", "Controlled vocabulary reference per dimension", "Whether values are mutually exclusive" ] }, { "id": "q-class-vocabulary-authority", "text": "Which authority governs each controlled vocabulary used for typing?", "kind": "authority", "answer_data": [ "Vocabulary owner and version", "Namespace URI", "Change-notification route" ] }, { "id": "q-class-reason", "text": "How is the business reason for the interaction distinguished from its outcome?", "kind": "definition", "answer_data": [ "Reason code at open time", "Outcome code at close time", "Rule preventing conflation of the two" ] }, { "id": "q-class-priority", "text": "What determines the priority value recorded on the interaction?", "kind": "constraint", "answer_data": [ "Priority code set", "Assignment rule or source", "Whether priority may change during the lifecycle" ] } ], "data_elements": [ { "id": "de-interaction-category", "name": "Interaction Category", "description": "Business category of the interaction, drawn from a governed vocabulary.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-interaction-reason", "name": "Interaction Reason", "description": "Declared reason the interaction occurred, as in the TMF683 reason attribute.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-interaction-priority", "name": "Interaction Priority", "description": "Priority code applied to the interaction.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-activity-verb", "name": "Activity Verb", "description": "Activity Streams style verb characterising the act performed (for example Create, Announce, Invite, Read).", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Classification is a set of coded values bound to externally governed vocabularies; the vocabularies themselves are owned by registry siblings, so this finding carries only inline code values and namespace bindings rather than any artifact of its own." } ] }, { "id": "identity-and-correlation", "name": "Identity and Correlation", "description": "Identifier assignment for the interaction and its turns, and the correlation keys that hold a conversation together across channels and systems.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-009" ], "findings": [ { "id": "interaction-identity-and-correlation", "name": "Interaction Identity and Correlation Keys", "description": "How the interaction root and each turn are identified, which identifier is authoritative, and which secondary keys (channel-native message IDs, thread IDs, room IDs, provider references) support correlation without becoming the identity.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-009", "SRC-012" ], "questions": [ { "id": "q-id-authoritative", "text": "Which system holds the authoritative identifier for this interaction record?", "kind": "identity", "answer_data": [ "Master system name and identifier scheme", "Identifier format and uniqueness guarantee", "Fallback scheme when no master system exists" ] }, { "id": "q-id-turn-native", "text": "How are channel-native message identifiers retained alongside the internal turn identifier?", "kind": "interoperability", "answer_data": [ "Native identifier value and issuing namespace", "Mapping to the internal turn identifier", "Stability guarantee of the native identifier" ] }, { "id": "q-id-correlation-keys", "text": "Which correlation keys allow the same conversation to be recognised across two channels?", "kind": "relationship", "answer_data": [ "Ordered correlation key list", "Match confidence per key", "Resolution rule when keys conflict" ] }, { "id": "q-id-merge-split", "text": "What happens to identifiers when two interaction records are merged or one is split?", "kind": "lifecycle", "answer_data": [ "Surviving identifier rule", "Superseded-by and supersedes links", "Retention of the withdrawn identifier as an alias" ] } ], "data_elements": [ { "id": "de-interaction-id", "name": "Interaction Identifier", "description": "Authoritative identifier of the interaction root.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-turn-native-id", "name": "Turn Native Identifier", "description": "Channel-native identifier of a turn, such as an RFC 5322 Message-ID, a Matrix event ID or a provider message ID.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-009", "SRC-012" ] }, { "id": "de-correlation-key", "name": "Correlation Key", "description": "Key used to associate turns or interactions across channels or systems.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-identifier-alias", "name": "Identifier Alias", "description": "Retired or alternate identifier retained after merge, split or migration.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Identifiers and correlation keys are scalar reference data with no document form; they are held inline on the interaction root and its turns so that resolution can be performed without dereferencing an artifact store." } ] } ] }, { "id": "participants-and-channels", "name": "Participants, Roles and Channel Binding", "description": "Who is party to the interaction and in what role, and through which channel and endpoint each of them is reachable.", "rationale": "TMF683 models relatedParty and channel as separate arrays; Matrix separates membership state from room configuration; and CPaaS practice separates a participant identity from its messaging binding. Conflating party, role, channel and address is the most common modelling failure in this domain.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005", "SRC-012" ], "layers": [ { "id": "participant-roster-and-roles", "name": "Participant Roster and Roles", "description": "The set of parties attached to the interaction, their communication roles, and how that membership changes over the interaction's life.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-005" ], "findings": [ { "id": "participant-roles-and-party-references", "name": "Participant Roles and Party References", "description": "How each participant is referenced into the external party model and which communication role they hold - initiator, addressee, copied, blind-copied, observer or handling agent - including visibility rules attached to the role.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-006", "SRC-009" ], "questions": [ { "id": "q-part-reference", "text": "How is each participant referenced into the authoritative party model?", "kind": "relationship", "answer_data": [ "Party reference identifier and referred type", "Role code held in this interaction", "Whether an unresolved external party may be recorded" ] }, { "id": "q-part-role-set", "text": "Which communication roles are permitted on a participant entry?", "kind": "classification", "answer_data": [ "Role vocabulary", "Cardinality limits per role", "Whether one party may hold several roles" ] }, { "id": "q-part-blind-visibility", "text": "How are blind-copied participants hidden from other participants of the same interaction?", "kind": "privacy", "answer_data": [ "Blind-recipient marker", "Redistribution suppression rule", "Retention policy for the suppressed value" ] }, { "id": "q-part-unidentified", "text": "How is an anonymous or not-yet-identified contact represented as a participant?", "kind": "exception", "answer_data": [ "Pseudonymous participant handle", "Later reconciliation procedure", "Constraints on downstream use of the record" ] } ], "data_elements": [ { "id": "de-participant-party-ref", "name": "Participant Party Reference", "description": "Reference to a party in the external party model, with referred type.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-participant-role", "name": "Participant Role", "description": "Communication role held by the participant in this interaction.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-blind-recipient-flag", "name": "Blind Recipient Flag", "description": "Marks a participant whose presence must not be redistributed to other participants.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Participants are typed references plus role codes; the party records themselves are owned by the party model, so reproducing them as artifacts here would duplicate a sibling model's master data." }, { "id": "participant-membership-lifecycle", "name": "Participant Membership Lifecycle", "description": "The states a participant passes through within the interaction - invited, active, departed, removed, barred - and the events that change them.", "source_refs": [ "SRC-003", "SRC-005" ], "questions": [ { "id": "q-memb-states", "text": "Which membership states may a participant occupy during the interaction?", "kind": "state", "answer_data": [ "Membership state vocabulary", "Permitted transitions", "Terminal states" ] }, { "id": "q-memb-transition-authority", "text": "Who is authorised to add or remove a participant mid-interaction?", "kind": "authority", "answer_data": [ "Authorising role", "Required justification", "Notification obligations to other participants" ] }, { "id": "q-memb-history-visibility", "text": "What portion of prior turns becomes visible to a participant joining late?", "kind": "access", "answer_data": [ "History visibility setting", "Effective-from turn index", "Whether the setting can change retroactively" ] } ], "data_elements": [ { "id": "de-membership-state", "name": "Membership State", "description": "Current membership state of a participant within the interaction.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-membership-change-time", "name": "Membership Change Time", "description": "Time at which the participant's membership state last changed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-history-visibility", "name": "History Visibility Setting", "description": "Rule governing how much prior content a joining participant may see.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": "Membership states and their change times are inline state values on the participant entry; the enforcement of history visibility is executed by the access model, so no artifact is produced here.", "artifacts": [] } ] }, { "id": "channel-and-endpoint-binding", "name": "Channel and Endpoint Binding", "description": "The channels used, their capability constraints, the endpoint addresses bound to each participant, and the direction of the exchange.", "source_refs": [ "SRC-001", "SRC-005", "SRC-009", "SRC-012" ], "findings": [ { "id": "channel-classification-and-capability", "name": "Channel Classification and Capability", "description": "Which channel each turn used, how channels are typed, and which capability constraints (message size, media types, template requirements, encryption, synchronicity) the channel imposes on the interaction.", "source_refs": [ "SRC-001", "SRC-005", "SRC-012" ], "questions": [ { "id": "q-chan-vocabulary", "text": "Which controlled vocabulary types the channel of an interaction or turn?", "kind": "classification", "answer_data": [ "Channel code list and owner", "Channel-versus-medium distinction", "Extension rule for new channels" ] }, { "id": "q-chan-capability", "text": "Which channel capability constraints must be recorded to explain what was sendable?", "kind": "constraint", "answer_data": [ "Maximum payload size and media types", "Template-versus-free-form requirement", "Synchronous or asynchronous mode" ] }, { "id": "q-chan-multiple", "text": "How does one interaction record more than one channel across its turns?", "kind": "composition", "answer_data": [ "Channel binding per turn", "Primary channel of the interaction", "Channel change event record" ] }, { "id": "q-chan-encryption", "text": "Is the channel end-to-end encrypted, and what does that imply for stored content?", "kind": "security", "answer_data": [ "Encryption mode indicator", "Whether plaintext content is retrievable by the operator", "Metadata retained when content is not" ] } ], "data_elements": [ { "id": "de-channel-ref", "name": "Channel Reference", "description": "Reference to the channel through which a turn or interaction occurred.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-channel-capability", "name": "Channel Capability Constraint", "description": "Recorded capability limit of the channel applicable at the time of the turn.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-encryption-mode", "name": "Encryption Mode", "description": "Indicator of whether the channel applied end-to-end encryption to turn content.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Channel typing and capability limits are coded reference values bound to an external channel registry; the registry entries themselves are a sibling model's records, so this finding stays inline." }, { "id": "endpoint-binding-and-direction", "name": "Endpoint Binding and Direction", "description": "The concrete endpoint addresses used at each end of a turn, including proxy or service-owned addresses, and the direction and initiation attribution of the exchange.", "source_refs": [ "SRC-001", "SRC-009", "SRC-012" ], "questions": [ { "id": "q-end-address-pair", "text": "Which endpoint address pair carried each turn?", "kind": "identity", "answer_data": [ "Participant address and its scheme", "Service-owned or proxy address", "Address normalisation rule applied" ] }, { "id": "q-end-direction", "text": "How is the direction of the interaction determined and recorded?", "kind": "definition", "answer_data": [ "Direction code (inbound, outbound, internal)", "Reference point defining inbound versus outbound", "Behaviour for mixed-direction interactions" ] }, { "id": "q-end-initiator", "text": "Which participant initiated the interaction and by what evidence?", "kind": "provenance", "answer_data": [ "Initiating participant reference", "First turn identifier and its timestamp", "Evidence when initiation is inferred rather than observed" ] }, { "id": "q-end-address-change", "text": "How is a change of a participant's endpoint mid-interaction recorded?", "kind": "event", "answer_data": [ "Superseded binding with validity period", "Reason for the change", "Effect on delivery evidence already recorded" ] } ], "data_elements": [ { "id": "de-endpoint-address", "name": "Endpoint Address", "description": "Normalised address of a participant on a channel, with its addressing scheme.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] }, { "id": "de-proxy-address", "name": "Service Proxy Address", "description": "Service-owned address that the participant address was paired with for this binding.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-direction-code", "name": "Direction Code", "description": "Direction of the interaction relative to the recording organisation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-binding-validity", "name": "Binding Validity Period", "description": "Period during which an endpoint binding was in force for this interaction.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Endpoint bindings are address values plus validity periods held on the interaction; the authoritative contact-point registry is a sibling model, and materialising addresses as artifacts would create an uncontrolled second copy of personal contact data." } ] } ] }, { "id": "turns-content-and-threading", "name": "Turns, Content and Threading", "description": "The ordered turns that make up the interaction, the content they carried, and the relations that thread them to each other and to other records.", "rationale": "JMAP defines threads as computed membership over identifier headers, Matrix defines explicit relation events, and TMF683 carries interactionItem and interactionRelationship. Content and threading are therefore distinct concerns that must be modelled separately from the interaction root.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-009" ], "layers": [ { "id": "turn-and-content-structure", "name": "Turn and Content Structure", "description": "Structure of an individual turn and of the content and attachments it carried.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-006" ], "findings": [ { "id": "turn-record-structure", "name": "Turn Record Structure", "description": "The minimum structure of one turn: author, sequence position, channel binding, timestamps, subject or topic, and the reference to its content.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-006" ], "questions": [ { "id": "q-turn-minimum", "text": "What is the minimum viable set of fields for a recorded turn?", "kind": "requirement", "answer_data": [ "Mandatory field list", "Behaviour when the author is unknown", "Behaviour when content is unavailable" ] }, { "id": "q-turn-ordering", "text": "How is the canonical order of turns determined when timestamps disagree?", "kind": "temporal", "answer_data": [ "Ordering key precedence", "Monotonic sequence index", "Tie-break rule" ] }, { "id": "q-turn-authorship", "text": "How is the acting author distinguished from the party on whose behalf the turn was sent?", "kind": "ownership", "answer_data": [ "Author reference", "On-behalf-of reference", "Automation or bot indicator" ] }, { "id": "q-turn-edit", "text": "How are edits, replacements and redactions of an already recorded turn represented?", "kind": "lifecycle", "answer_data": [ "Replacement relation to the original turn", "Redaction marker and residual metadata", "Whether the superseded content is retrievable" ] } ], "data_elements": [ { "id": "de-turn-id", "name": "Turn Identifier", "description": "Identifier of an individual turn within the interaction.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-turn-sequence", "name": "Turn Sequence Index", "description": "Monotonic index establishing canonical order of turns within the interaction.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-turn-author-ref", "name": "Turn Author Reference", "description": "Reference to the participant who authored the turn.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "de-turn-topic", "name": "Turn Topic", "description": "Subject or topic string carried by the turn.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "The turn envelope is structured metadata that must be queryable in place for ordering and threading; the payload it points to is handled as an artifact in the separate content finding, keeping envelope and content cleanly separated." }, { "id": "content-payload-and-attachments", "name": "Content Payload and Attachments", "description": "The renderable content of a turn and any attached files, including media type, size, integrity digest, language and the distinction between inline body parts and downloadable attachments.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-006" ], "questions": [ { "id": "q-content-representations", "text": "Which alternative representations of the same turn content are retained?", "kind": "composition", "answer_data": [ "Plain-text body reference", "Rich or HTML body reference", "Structured or template payload reference" ] }, { "id": "q-content-attachment-boundary", "text": "What distinguishes an inline body part from a downloadable attachment?", "kind": "definition", "answer_data": [ "Disposition indicator", "Media type and size", "Rendering expectation" ] }, { "id": "q-content-integrity", "text": "How is the integrity of stored content and attachments demonstrated?", "kind": "evidence", "answer_data": [ "Digest algorithm and value", "Byte size at capture", "Verification time and result" ] }, { "id": "q-content-language", "text": "In which language and script was the content expressed?", "kind": "quality", "answer_data": [ "Language tag", "Whether the content is a machine translation", "Reference to the source-language turn" ] } ], "data_elements": [ { "id": "de-content-media-type", "name": "Content Media Type", "description": "Media type of a content part or attachment.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "de-content-digest", "name": "Content Digest", "description": "Cryptographic digest of the stored content bytes with the algorithm identifier.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-content-language-tag", "name": "Content Language Tag", "description": "Language tag of the content part.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-attachment-size", "name": "Attachment Size", "description": "Size of the attachment as captured.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "art-turn-content-part", "name": "Turn Content Part", "description": "A renderable body part of a turn, retained in the representation in which it was sent or received.", "media_or_form": [ "plain text body", "rich text or HTML body", "structured template payload", "voice or video stream segment" ], "serial": true, "identity_strategy": "Identified by the channel-native content-part identifier where the channel issues one; otherwise by the interaction identifier plus turn identifier plus part index, with a content digest recorded for integrity.", "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "art-turn-attachment", "name": "Turn Attachment", "description": "A discrete file or media object attached to a turn and retained as a downloadable object.", "media_or_form": [ "document file", "image", "audio file", "video file", "structured data file" ], "serial": true, "identity_strategy": "Identified by the attachment identifier issued by the content store as master system; the channel-native attachment reference and a content digest are retained as correlation keys.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "id": "threading-and-linkage", "name": "Threading and Linkage", "description": "Relations among turns and interactions, and links from the interaction to records owned by other models.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005", "SRC-009" ], "findings": [ { "id": "thread-and-reply-relations", "name": "Thread and Reply Relations", "description": "How reply chains and threads are derived or asserted, covering identifier-based derivation, explicit relation events, and the treatment of subject-line heuristics.", "source_refs": [ "SRC-004", "SRC-005", "SRC-009" ], "questions": [ { "id": "q-thread-membership-rule", "text": "By what rule is thread membership of a turn decided?", "kind": "relationship", "answer_data": [ "Identifier chain rule using reply and reference fields", "Explicit relation assertion type", "Whether subject normalisation participates in the rule" ] }, { "id": "q-thread-derived-or-asserted", "text": "Is the thread a derived view or a stored asserted relation?", "kind": "provenance", "answer_data": [ "Derivation flag", "Algorithm and version used", "Recomputation trigger conditions" ] }, { "id": "q-thread-cross-channel", "text": "Can a thread span more than one channel, and how is that asserted?", "kind": "interoperability", "answer_data": [ "Cross-channel thread policy", "Bridging correlation key", "Confidence qualifier on the bridge" ] }, { "id": "q-thread-conflict", "text": "How is a conflict resolved when identifier evidence and asserted threading disagree?", "kind": "exception", "answer_data": [ "Precedence rule", "Conflict marker retained on the record", "Escalation route for manual adjudication" ] } ], "data_elements": [ { "id": "de-thread-ref", "name": "Thread Reference", "description": "Identifier of the thread to which a turn belongs.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-in-reply-to-ref", "name": "In-Reply-To Reference", "description": "Reference from a turn to the turn it directly answers.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-009" ] }, { "id": "de-reference-chain", "name": "Reference Chain", "description": "Ordered ancestor identifier chain retained from the channel-native headers.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-thread-derivation-method", "name": "Thread Derivation Method", "description": "Named method and version by which thread membership was computed.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Threading is a relation graph over identifiers plus a declared derivation method; it is queryable inline data with no document form, and materialising it as an artifact would freeze a view that must be recomputable." }, { "id": "linkage-to-external-records", "name": "Linkage to External Records", "description": "Typed links from the interaction to records owned elsewhere - the request or order that prompted it, the case or encounter it belongs to, the subject it concerns, and sibling interactions.", "source_refs": [ "SRC-001", "SRC-002" ], "questions": [ { "id": "q-link-types", "text": "Which typed link roles may an interaction hold to records outside this model?", "kind": "relationship", "answer_data": [ "Link role vocabulary such as based-on, part-of, in-response-to, about", "Target model identifier", "Cardinality per role" ] }, { "id": "q-link-subject", "text": "Who or what is the subject the interaction is about, as opposed to its participants?", "kind": "definition", "answer_data": [ "Subject reference and referred type", "Rule distinguishing subject from recipient", "Handling when subject and participant coincide" ] }, { "id": "q-link-integrity", "text": "What happens to a link when the target record is withdrawn or merged?", "kind": "validation", "answer_data": [ "Dangling reference policy", "Redirect or superseded-by resolution", "Marker retained on the interaction" ] } ], "data_elements": [ { "id": "de-link-role", "name": "Link Role", "description": "Typed role of a link from the interaction to an external record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-link-target-ref", "name": "Link Target Reference", "description": "Reference to the external record, with its owning model or referred type.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-subject-ref", "name": "Interaction Subject Reference", "description": "Reference to the entity the interaction concerns.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Links are typed references whose targets are owned by other models; recording them inline preserves the ownership boundary, whereas an artifact copy would duplicate target-model state." } ] } ] }, { "id": "lifecycle-time-and-outcome", "name": "Lifecycle, Time and Outcome", "description": "The state the interaction is in, who is handling it, the time points and windows that govern it, and how it concludes.", "rationale": "TMF683 defines an explicit status lifecycle with statusChangeDate and status-change events; FHIR binds status to EventStatus including not-done and entered-in-error; channel rules impose hard engagement windows. These are distinct but interdependent concerns.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-012" ], "layers": [ { "id": "interaction-state", "name": "Interaction State and Handling", "description": "Lifecycle states of the interaction record and the assignment of responsibility for handling it.", "source_refs": [ "SRC-001", "SRC-002" ], "findings": [ { "id": "interaction-state-machine", "name": "Interaction State Machine", "description": "The permitted lifecycle states of the interaction, the transitions between them, the reasons recorded on transition, and the treatment of erroneous records.", "source_refs": [ "SRC-001", "SRC-002" ], "questions": [ { "id": "q-state-values", "text": "Which lifecycle states may an interaction record occupy?", "kind": "state", "answer_data": [ "State vocabulary and its binding strength", "Initial and terminal states", "Mapping to external state vocabularies" ] }, { "id": "q-state-transitions", "text": "Which state transitions are permitted and which are forbidden?", "kind": "lifecycle", "answer_data": [ "Transition matrix", "Guard conditions per transition", "Reversibility of terminal states" ] }, { "id": "q-state-reason", "text": "What reason must accompany a transition to a non-completion state?", "kind": "requirement", "answer_data": [ "Status reason code", "Free-text justification", "Recording actor reference" ] }, { "id": "q-state-erroneous", "text": "How is a record created in error withdrawn without destroying evidence?", "kind": "exception", "answer_data": [ "Entered-in-error state marker", "Preservation rule for the withdrawn content", "Downstream notification obligation" ] } ], "data_elements": [ { "id": "de-interaction-status", "name": "Interaction Status", "description": "Current lifecycle state of the interaction record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-status-change-time", "name": "Status Change Time", "description": "Time at which the interaction status last changed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-status-reason", "name": "Status Reason", "description": "Reason recorded for the current status, particularly for non-completion.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Lifecycle state is a single governed code plus change time and reason held on the interaction root; it must be atomically updatable and queryable inline, and it produces no separate document." }, { "id": "handling-assignment-state", "name": "Handling Assignment State", "description": "Which queue, team or individual currently holds responsibility for the interaction, how that assignment changed, and what accountability the assignment establishes.", "source_refs": [ "SRC-001", "SRC-005" ], "questions": [ { "id": "q-assign-holder", "text": "Who currently holds handling responsibility for this interaction?", "kind": "ownership", "answer_data": [ "Assignee reference and role", "Queue or team reference", "Assignment effective time" ] }, { "id": "q-assign-transfer", "text": "How is a transfer of handling responsibility recorded?", "kind": "process", "answer_data": [ "Previous and new assignee references", "Transfer reason", "Whether the transfer was accepted or declined" ] }, { "id": "q-assign-unassigned", "text": "What represents an interaction that is awaiting assignment?", "kind": "state", "answer_data": [ "Unassigned marker", "Waiting-time accumulation start", "Escalation threshold reference" ] } ], "data_elements": [ { "id": "de-assignee-ref", "name": "Assignee Reference", "description": "Reference to the party or queue currently responsible for handling the interaction.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-assignment-time", "name": "Assignment Effective Time", "description": "Time from which the current assignment is in force.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-assignment-history", "name": "Assignment History Entry", "description": "Prior assignment with its validity period and transfer reason.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Assignment is mutable inline state on the interaction root; routing decisions and workforce allocation are executed by external systems, so this model records only the resulting responsibility holder." } ] }, { "id": "temporal-semantics", "name": "Temporal Semantics", "description": "The time points, periods and channel-imposed windows that govern the interaction.", "source_refs": [ "SRC-001", "SRC-004", "SRC-010", "SRC-012" ], "findings": [ { "id": "interaction-time-points", "name": "Interaction Time Points and Periods", "description": "Which distinct times are recorded - authored, sent, received by the store, delivered, read, observed, ingested - the interaction period as a whole, and the timestamp format and offset requirements.", "source_refs": [ "SRC-004", "SRC-006", "SRC-009", "SRC-010" ], "questions": [ { "id": "q-time-distinct-points", "text": "Which distinct time points must be recorded separately rather than collapsed?", "kind": "temporal", "answer_data": [ "Named time-point list with definitions", "Which points are mandatory", "Rule forbidding substitution between points" ] }, { "id": "q-time-format", "text": "What timestamp format, precision and offset are required?", "kind": "constraint", "answer_data": [ "RFC 3339 profile with seconds", "Offset representation rule including Z and unknown-offset convention", "Sub-second precision policy" ] }, { "id": "q-time-clock-authority", "text": "Whose clock authoritatively stamps each recorded time point?", "kind": "provenance", "answer_data": [ "Clock owner per time point", "Known skew or accuracy bound", "Behaviour when a supplied timestamp is implausible" ] }, { "id": "q-time-period", "text": "How is the overall interaction period bounded for a long-running asynchronous conversation?", "kind": "measurement", "answer_data": [ "Period start and end rule", "Treatment of an open-ended period", "Effect of reopening on the period" ] } ], "data_elements": [ { "id": "de-authored-time", "name": "Authored Time", "description": "Time the author declared the turn complete, independent of transmission.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-received-time", "name": "Store Received Time", "description": "Time the recording store received the turn, distinct from the author-declared time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-observation-time", "name": "Observation or Ingestion Time", "description": "Time this model's record of the event was created or ingested.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-interaction-period", "name": "Interaction Period", "description": "Period during which the interaction took place, with start and optional end.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Time points are scalar values on the interaction and its turns and must be directly comparable and indexable; expressing them as artifacts would prevent the ordering and window calculations that depend on them." }, { "id": "engagement-windows-and-timers", "name": "Engagement Windows and Timers", "description": "Channel- and rule-imposed windows that constrain when a party may be contacted or a free-form reply may be sent, and the timers that close or reclassify an interaction.", "source_refs": [ "SRC-007", "SRC-008", "SRC-012" ], "questions": [ { "id": "q-window-open", "text": "Which event opens a channel engagement window and when does it expire?", "kind": "event", "answer_data": [ "Window-opening event type", "Window duration and reset behaviour", "Expiry timestamp" ] }, { "id": "q-window-effect", "text": "What changes about permissible outbound content once the window has closed?", "kind": "constraint", "answer_data": [ "Free-form versus pre-approved template requirement", "Category of permitted template", "Record of which form was used" ] }, { "id": "q-window-time-of-day", "text": "Which time-of-day or calendar restrictions applied to outbound contact?", "kind": "requirement", "answer_data": [ "Permitted contact hours in the recipient's local time", "Locale used to determine local time", "Exception basis where contact fell outside the window" ] }, { "id": "q-window-inactivity", "text": "Which inactivity timers change the interaction state automatically?", "kind": "process", "answer_data": [ "Timer name and duration", "Resulting state transition", "Whether the transition is reversible on a later reply" ] } ], "data_elements": [ { "id": "de-engagement-window", "name": "Engagement Window", "description": "Channel session window with its opening event, duration and expiry.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-contact-hours-constraint", "name": "Contact Hours Constraint", "description": "Permitted contact hours applied to an outbound turn, expressed in the recipient's local time.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-inactivity-timer", "name": "Inactivity Timer", "description": "Configured inactivity duration that triggers an automatic state transition.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Windows and timers are durations and computed expiry timestamps evaluated against the interaction; the rules that set them are owned by channel and permission models, so only the applied values are held here inline." } ] }, { "id": "outcome-and-disposition", "name": "Outcome and Disposition", "description": "How the interaction concluded, what was resolved, and the human or automated wrap-up recorded against it.", "source_refs": [ "SRC-001", "SRC-002" ], "findings": [ { "id": "outcome-and-wrap-up-record", "name": "Outcome and Wrap-Up Record", "description": "The recorded outcome, resolution and follow-up commitment for the interaction, together with the notes authored at close, distinguishing outcome from lifecycle state.", "source_refs": [ "SRC-001", "SRC-002" ], "questions": [ { "id": "q-outcome-vocabulary", "text": "Which outcome and resolution values may be recorded at close?", "kind": "classification", "answer_data": [ "Outcome code list", "Resolution text or code", "Rule separating outcome from lifecycle status" ] }, { "id": "q-outcome-author", "text": "Who authored the wrap-up note and were they human or automated?", "kind": "provenance", "answer_data": [ "Note author reference", "Automation indicator and model or system identifier", "Authoring timestamp" ] }, { "id": "q-outcome-followup", "text": "What follow-up commitment was made and where is it tracked?", "kind": "process", "answer_data": [ "Commitment description and due time", "Reference to the record where it is tracked", "Whether the interaction remains open pending it" ] }, { "id": "q-outcome-quality", "text": "How is the reliability of a generated summary distinguished from a verified one?", "kind": "quality", "answer_data": [ "Generation method indicator", "Human verification status and verifier", "Confidence or review marker" ] } ], "data_elements": [ { "id": "de-outcome-code", "name": "Outcome Code", "description": "Coded outcome of the interaction, distinct from its lifecycle status.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-resolution-text", "name": "Resolution Statement", "description": "Statement of what was resolved by the interaction.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-followup-commitment", "name": "Follow-Up Commitment", "description": "Commitment made during the interaction, with due time and tracking reference.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "art-interaction-wrap-up-note", "name": "Interaction Wrap-Up Note", "description": "Authored note or summary recorded against the interaction at or after close, retained with its author and authoring time.", "media_or_form": [ "free-text note", "structured disposition summary", "generated conversation summary" ], "serial": true, "identity_strategy": "Identified by the note identifier assigned by the recording system as master; where several notes exist they are ordered by authoring time and each retains its author reference and generation method.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "evidence-provenance-and-measurement", "name": "Delivery Evidence, Provenance and Measurement", "description": "What can be demonstrated about the interaction: whether it reached its recipient, who observed it, what was captured, and what is measured from it.", "rationale": "Acceptance by a platform is explicitly not delivery, JMAP separates submission state from message state, and MiFID II-style regimes require faithful capture on a durable medium. Evidence, provenance and measurement therefore need explicit modelling rather than being inferred from status.", "source_refs": [ "SRC-004", "SRC-005", "SRC-012", "SRC-013" ], "layers": [ { "id": "delivery-and-receipt-evidence", "name": "Delivery and Receipt Evidence", "description": "Evidence of what happened to a turn after it was submitted, and of recipient engagement with it.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-012" ], "findings": [ { "id": "delivery-status-evidence", "name": "Delivery Status Evidence", "description": "The chain of submission and delivery outcomes recorded for an outbound turn - accepted, sent, delivered, failed, expired - each with its reporting source, timestamp and failure reason.", "source_refs": [ "SRC-004", "SRC-012" ], "questions": [ { "id": "q-del-status-chain", "text": "Which delivery outcome states are recorded for an outbound turn and in what order?", "kind": "state", "answer_data": [ "Delivery state vocabulary", "Permitted state progression", "Terminal failure states" ] }, { "id": "q-del-acceptance-vs-delivery", "text": "How is platform acceptance of a send request distinguished from actual delivery?", "kind": "evidence", "answer_data": [ "Acceptance acknowledgement identifier", "Separate delivery confirmation record", "Explicit statement that acceptance is not delivery" ] }, { "id": "q-del-failure-reason", "text": "What failure reason and reporting authority are recorded for an undelivered turn?", "kind": "exception", "answer_data": [ "Failure reason code and originating system", "Whether the failure is permanent or transient", "Retry attempts and their outcomes" ] }, { "id": "q-del-per-recipient", "text": "How is delivery evidence held separately for each recipient of a multi-recipient turn?", "kind": "composition", "answer_data": [ "Per-recipient delivery entry", "Aggregation rule for the turn as a whole", "Handling of recipients with no reporting channel" ] } ], "data_elements": [ { "id": "de-delivery-state", "name": "Delivery State", "description": "Reported delivery outcome for a turn to a specific recipient.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-delivery-report-time", "name": "Delivery Report Time", "description": "Time at which a delivery outcome was reported.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-delivery-failure-reason", "name": "Delivery Failure Reason", "description": "Reason code and reporting system for a failed or expired delivery.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "art-delivery-status-receipt", "name": "Delivery Status Receipt", "description": "Machine-generated receipt or notification received from a transport or platform reporting the fate of a submitted turn, retained as received.", "media_or_form": [ "delivery status notification message", "platform status callback payload", "carrier delivery report" ], "serial": true, "identity_strategy": "Identified by the receipt identifier issued by the reporting transport or platform as master system; correlated to the turn by the platform message identifier retained as a correlation key.", "source_refs": [ "SRC-004", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "engagement-and-read-signals", "name": "Engagement and Read Signals", "description": "Signals that a recipient opened, read or acted on a turn, and the honest limits of what each signal proves.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-012" ], "questions": [ { "id": "q-eng-signal-types", "text": "Which engagement signals are captured for a turn?", "kind": "measurement", "answer_data": [ "Signal type list such as read receipt, seen flag, open, click", "Capture source per signal", "Timestamp of the signal" ] }, { "id": "q-eng-reliability", "text": "What does each engagement signal actually evidence, and what does it not?", "kind": "quality", "answer_data": [ "Signal semantics statement", "Known false-positive and false-negative causes", "Confidence qualifier" ] }, { "id": "q-eng-consent-to-signal", "text": "Under what conditions may read or open tracking be recorded at all?", "kind": "privacy", "answer_data": [ "Reference to the permitting decision", "Channel setting that disables receipts", "Behaviour when tracking is not permitted" ] }, { "id": "q-eng-attribution", "text": "To which participant is an engagement signal attributed when several share an endpoint?", "kind": "identity", "answer_data": [ "Attribution rule", "Ambiguity marker", "Effect on derived measures" ] } ], "data_elements": [ { "id": "de-engagement-signal", "name": "Engagement Signal", "description": "Captured signal of recipient engagement with a turn, with type, source and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-012" ] }, { "id": "de-read-state-flag", "name": "Read State Flag", "description": "Per-participant read or seen marker on a turn.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-signal-confidence", "name": "Signal Confidence", "description": "Qualifier expressing how strongly a signal evidences actual recipient attention.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Engagement signals are timestamped scalar observations attached to a turn and its participants; they are aggregated and queried in place and have no standalone document form distinct from the delivery receipt artifact already modelled." } ] }, { "id": "provenance-and-capture", "name": "Provenance and Capture", "description": "Which system observed, authored or reconstructed the record, and what durable capture exists of the exchange itself.", "source_refs": [ "SRC-001", "SRC-004", "SRC-013" ], "findings": [ { "id": "capture-provenance-and-system-of-record", "name": "Capture Provenance and System of Record", "description": "Attribution of the interaction record to the system that captured it, the fidelity of that capture, and which system is authoritative when several hold a version.", "source_refs": [ "SRC-001", "SRC-004", "SRC-013" ], "questions": [ { "id": "q-prov-capturing-system", "text": "Which system captured this interaction record and by what method?", "kind": "provenance", "answer_data": [ "Capturing system identifier and version", "Capture method such as native, connector or manual entry", "Capture timestamp" ] }, { "id": "q-prov-authority", "text": "Which holder is authoritative when several systems hold a version of the same interaction?", "kind": "authority", "answer_data": [ "System-of-record designation", "Precedence rule between holders", "Reconciliation procedure on divergence" ] }, { "id": "q-prov-fidelity", "text": "How faithful is the stored record to the original exchange?", "kind": "quality", "answer_data": [ "Fidelity level such as verbatim, normalised or summarised", "Known lossy transformations applied", "Original form retention status" ] }, { "id": "q-prov-manual-entry", "text": "How is a manually entered or reconstructed interaction distinguished from an observed one?", "kind": "validation", "answer_data": [ "Entry method marker", "Entering party reference", "Restrictions on evidentiary use" ] } ], "data_elements": [ { "id": "de-capturing-system", "name": "Capturing System", "description": "Identifier and version of the system that captured the interaction record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-capture-method", "name": "Capture Method", "description": "Method by which the record was created, such as native capture, connector import or manual entry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "de-fidelity-level", "name": "Fidelity Level", "description": "Declared faithfulness of the stored record relative to the original exchange.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Provenance is attribution metadata carried on the record itself so that any consumer can judge its weight without a second lookup; the audit trail of who later accessed or changed it is owned by the audit model and is deliberately not reproduced here." }, { "id": "recording-and-transcript-material", "name": "Recording and Transcript Material", "description": "Durable capture of the exchange itself - media recordings and transcripts - with their notification basis, integrity protection and relationship to the turns they evidence.", "source_refs": [ "SRC-005", "SRC-007", "SRC-013" ], "questions": [ { "id": "q-rec-basis", "text": "On what basis was the exchange recorded, and were participants notified?", "kind": "authority", "answer_data": [ "Recording basis reference", "Notification evidence and its timing", "Jurisdictions where all-party notification applied" ] }, { "id": "q-rec-integrity", "text": "How is a recording protected against undetected alteration?", "kind": "security", "answer_data": [ "Durable medium statement", "Digest or seal value", "Verification history" ] }, { "id": "q-rec-transcript-link", "text": "How does a transcript segment map onto the turns it represents?", "kind": "composition", "answer_data": [ "Segment offset or span", "Turn or speaker attribution", "Transcription method and accuracy indicator" ] }, { "id": "q-rec-unavailable", "text": "What is recorded when the exchange should have been captured but was not?", "kind": "exception", "answer_data": [ "Capture gap marker with reason", "Time span not covered", "Remediation or reporting action taken" ] } ], "data_elements": [ { "id": "de-recording-basis-ref", "name": "Recording Basis Reference", "description": "Reference to the decision or obligation under which the exchange was recorded.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-013" ] }, { "id": "de-capture-gap", "name": "Capture Gap", "description": "Recorded span for which expected capture is missing, with its reason.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-transcription-method", "name": "Transcription Method", "description": "Method and accuracy indicator for a transcript, including whether it was machine generated.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "art-interaction-media-recording", "name": "Interaction Media Recording", "description": "Durable audio, video or screen recording of the exchange, retained on a medium that prevents undetected alteration.", "media_or_form": [ "audio recording", "video recording", "screen or session recording" ], "serial": true, "identity_strategy": "Identified by the recording identifier issued by the capture platform as master system; bound to the interaction identifier and to a covered time span, with an integrity digest recorded at capture.", "source_refs": [ "SRC-013" ] }, { "id": "art-interaction-transcript", "name": "Interaction Transcript", "description": "Textual transcript of a recorded exchange, segmented and attributed to speakers or turns.", "media_or_form": [ "timed text transcript", "speaker-attributed text document", "structured transcript segments" ], "serial": true, "identity_strategy": "Identified by the transcript identifier assigned by the producing system, carrying a reference to the source recording identifier and the transcription method and version used.", "source_refs": [ "SRC-005", "SRC-013" ] } ], "inline_only_rationale": null } ] }, { "id": "interaction-measurement", "name": "Interaction Measurement", "description": "Quantities derived from the interaction record and the definitions that make them comparable.", "source_refs": [ "SRC-001", "SRC-004", "SRC-010" ], "findings": [ { "id": "interaction-measures", "name": "Interaction Measures and Their Definitions", "description": "Counts and durations computed from the interaction - turn counts, response latency, handling duration, wait time, transfer count - each with an explicit definition, unit and derivation base.", "source_refs": [ "SRC-001", "SRC-004", "SRC-010" ], "questions": [ { "id": "q-meas-definitions", "text": "How is each derived measure defined in terms of recorded time points?", "kind": "measurement", "answer_data": [ "Measure name and formula", "Start and end time points used", "Unit and precision" ] }, { "id": "q-meas-exclusions", "text": "Which periods are excluded from a duration measure and why?", "kind": "constraint", "answer_data": [ "Excluded period types such as out-of-hours or on-hold", "Exclusion rule and its owner", "Effect on comparability across channels" ] }, { "id": "q-meas-storage", "text": "Are measures stored as materialised values or recomputed on demand?", "kind": "decision", "answer_data": [ "Materialisation policy", "Recomputation trigger", "Version of the definition applied to a stored value" ] } ], "data_elements": [ { "id": "de-turn-count", "name": "Turn Count", "description": "Number of turns recorded in the interaction, optionally broken down by direction.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-response-latency", "name": "Response Latency", "description": "Elapsed time between a qualifying inbound turn and the first responding outbound turn.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-measure-definition-ref", "name": "Measure Definition Reference", "description": "Reference to the versioned definition under which a stored measure was computed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Measures are numeric values with a definition reference; they are derived from time points already held inline and are consumed as data, not as reports, since reporting outputs belong to an analytics model outside this boundary." } ] } ] }, { "id": "governance-and-interoperability", "name": "Permission, Confidentiality, Retention and Interoperability", "description": "The governance references the interaction record must carry, and the bindings that let it be exchanged and validated.", "rationale": "Direct-marketing consent, suppression, sender identification, confidentiality and retention are imposed by law on communication records, while cross-channel exchange requires explicit alignment bindings. This model must carry the references and markers without absorbing the evaluating or enforcing models.", "source_refs": [ "SRC-007", "SRC-008", "SRC-011", "SRC-013" ], "layers": [ { "id": "permission-and-contactability", "name": "Permission Basis and Contactability Signals", "description": "References to the permission decision that authorised an outbound contact, and the suppression or revocation signals observed within the interaction itself.", "source_refs": [ "SRC-007", "SRC-008", "SRC-011", "SRC-012" ], "findings": [ { "id": "permission-basis-reference", "name": "Permission Basis Reference", "description": "The reference this record carries to the permission or lawful-basis decision that was in force when an outbound turn was sent, together with the sender-identification content that had to accompany it.", "source_refs": [ "SRC-007", "SRC-008", "SRC-011", "SRC-012" ], "questions": [ { "id": "q-perm-decision-ref", "text": "Which permission decision authorised this outbound contact, and where is it held?", "kind": "authority", "answer_data": [ "Permission decision identifier and owning model", "Basis type recorded on the decision", "Time the decision was in force" ] }, { "id": "q-perm-snapshot", "text": "What minimum snapshot of the permission decision is retained on the interaction?", "kind": "evidence", "answer_data": [ "Decision identifier, basis code and version", "Evaluation timestamp", "Explicit statement that evaluation is not performed here" ] }, { "id": "q-perm-sender-identification", "text": "What sender identification and cessation route accompanied the outbound turn?", "kind": "requirement", "answer_data": [ "Identified sender name", "Valid address or route for requesting cessation", "Position of the identification within the message" ] }, { "id": "q-perm-missing", "text": "How is an outbound turn recorded when no permission reference can be resolved?", "kind": "exception", "answer_data": [ "Unresolved-basis marker", "Escalation or hold behaviour", "Reporting obligation triggered" ] } ], "data_elements": [ { "id": "de-permission-decision-ref", "name": "Permission Decision Reference", "description": "Reference to the permission or lawful-basis decision held in the permission model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-permission-basis-code", "name": "Permission Basis Code", "description": "Basis code copied from the referenced decision as a point-in-time snapshot.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-011" ] }, { "id": "de-sender-identification", "name": "Sender Identification", "description": "Identity presented as the sender and the address or route offered for requesting cessation.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "This finding deliberately holds only a reference and a point-in-time snapshot; the consent artefact, its evaluation and its withdrawal machinery are owned by the permission model, and copying them here as artifacts would duplicate that model's records and its decision semantics." }, { "id": "suppression-and-revocation-signals", "name": "Suppression and Revocation Signals in the Exchange", "description": "Recognition and recording of stop, unsubscribe or objection expressions that occur inside the interaction, as observations to be forwarded to the permission model rather than acted on here.", "source_refs": [ "SRC-007", "SRC-008", "SRC-011" ], "questions": [ { "id": "q-supp-recognition", "text": "Which expressions within a turn are recorded as revocation or objection signals?", "kind": "event", "answer_data": [ "Recognised keyword or gesture list per channel", "Recognition method and its version", "Verbatim source turn reference" ] }, { "id": "q-supp-handoff", "text": "How is a recognised revocation signal handed to the model that owns permission state?", "kind": "process", "answer_data": [ "Handoff message content and target model", "Handoff timestamp and acknowledgement", "Explicit non-ownership of the resulting permission change" ] }, { "id": "q-supp-timeliness", "text": "What evidence is retained about how quickly the signal was passed on?", "kind": "evidence", "answer_data": [ "Signal observation time", "Handoff time", "Elapsed interval against the applicable deadline" ] }, { "id": "q-supp-ambiguous", "text": "How is an ambiguous or partial revocation expression recorded?", "kind": "exception", "answer_data": [ "Ambiguity marker and confidence", "Escalation for human review", "Conservative default behaviour applied" ] } ], "data_elements": [ { "id": "de-revocation-signal", "name": "Revocation Signal Observation", "description": "Observation that a revocation, objection or stop expression occurred in a turn, with its source and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-signal-handoff-ref", "name": "Signal Handoff Reference", "description": "Reference to the notification sent to the permission model, with its acknowledgement.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-signal-recognition-method", "name": "Signal Recognition Method", "description": "Named method and version used to recognise the signal within the turn content.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "These are observations recorded against a turn and forwarded onward; the resulting suppression entry, its effective date and its enforcement are records of the permission model, so nothing artifactual is created within this boundary." } ] }, { "id": "confidentiality-access-and-retention", "name": "Confidentiality Markers and Retention Binding", "description": "Classification and redaction markers carried on the record, and the retention class bound to it for another model to execute.", "source_refs": [ "SRC-002", "SRC-005", "SRC-011", "SRC-013" ], "findings": [ { "id": "visibility-classification-and-redaction", "name": "Visibility Classification and Redaction Markers", "description": "Confidentiality classification of the interaction and its parts, plus redaction and masking markers that record what has been withheld and why, without performing enforcement.", "source_refs": [ "SRC-002", "SRC-005", "SRC-011" ], "questions": [ { "id": "q-vis-classification", "text": "What confidentiality classification applies to the interaction and to individual turns?", "kind": "security", "answer_data": [ "Classification code and vocabulary owner", "Scope of application, whole record or part", "Time from which the classification applies" ] }, { "id": "q-vis-special-category", "text": "Which parts of the content carry heightened sensitivity requiring extra handling?", "kind": "privacy", "answer_data": [ "Sensitivity marker and its scope", "Special-category indicator", "Reference to the handling rule that applies" ] }, { "id": "q-vis-redaction-record", "text": "What is retained about content that has been redacted or masked?", "kind": "validation", "answer_data": [ "Redaction marker with span or field reference", "Reason and authorising party", "Whether the original remains recoverable and by whom" ] }, { "id": "q-vis-enforcement-boundary", "text": "Which model evaluates and enforces access based on these markers?", "kind": "access", "answer_data": [ "Access-control model reference", "Statement that this model only carries markers", "Marker-to-policy binding identifier" ] } ], "data_elements": [ { "id": "de-confidentiality-class", "name": "Confidentiality Classification", "description": "Classification code applied to the interaction or one of its parts.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-redaction-marker", "name": "Redaction Marker", "description": "Marker recording that a span or field was redacted, with reason and authorising party.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-access-policy-binding", "name": "Access Policy Binding", "description": "Reference binding this record's markers to a policy held in the access-control model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Classification and redaction markers are metadata attached to the record and its parts; the evaluating policy, the enforcement decision and the resulting access log are owned by the access-control and audit models and are referenced rather than reproduced here." }, { "id": "retention-class-and-disposition-binding", "name": "Retention Class and Disposition Binding", "description": "The retention class bound to the interaction, the trigger that starts its retention period, any legal hold marker, and the tombstone left when disposition is executed elsewhere.", "source_refs": [ "SRC-008", "SRC-011", "SRC-013" ], "questions": [ { "id": "q-ret-class", "text": "Which retention class applies to this interaction and what triggers its period?", "kind": "retention", "answer_data": [ "Retention class identifier and owning schedule", "Retention trigger event and its timestamp", "Computed earliest disposition date" ] }, { "id": "q-ret-conflict", "text": "How is a conflict between competing retention obligations resolved on one record?", "kind": "constraint", "answer_data": [ "Competing obligation identifiers and periods", "Precedence rule applied", "Record of the resolved effective period" ] }, { "id": "q-ret-hold", "text": "What marks an interaction as being under a hold that suspends disposition?", "kind": "authority", "answer_data": [ "Hold marker with issuing authority reference", "Hold scope and start time", "Release condition and evidence" ] }, { "id": "q-ret-tombstone", "text": "What remains after disposition has been executed by the owning model?", "kind": "lifecycle", "answer_data": [ "Tombstone content and its minimum fields", "Disposition method and execution timestamp", "Reference to the executing model's disposition record" ] } ], "data_elements": [ { "id": "de-retention-class-ref", "name": "Retention Class Reference", "description": "Reference to the retention class in the owning retention schedule.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-retention-trigger-time", "name": "Retention Trigger Time", "description": "Timestamp of the event that starts the retention period for this record.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-hold-marker", "name": "Hold Marker", "description": "Marker suspending disposition, with the issuing authority reference and scope.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-disposition-tombstone", "name": "Disposition Tombstone", "description": "Minimal residual record left in place after disposition, referencing the executing model's disposition record.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Retention is expressed here as class bindings, trigger times, hold markers and a tombstone shape; the schedule, the disposition decision and its execution and certification belong to the retention model, so this finding produces no disposition artifact of its own." } ] }, { "id": "interoperability-and-validation", "name": "Interoperability and Validation", "description": "Alignment bindings to external interaction vocabularies, the validation rules that keep records defensible, and the handling of degraded or partial capture.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-006" ], "findings": [ { "id": "external-schema-alignment-bindings", "name": "External Schema Alignment Bindings", "description": "Declared, evidence-backed alignments between this model's elements and external interaction schemas and vocabularies, together with the conflicts those alignments expose.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-006" ], "questions": [ { "id": "q-align-targets", "text": "Which external interaction schemas is this record aligned to and at which version?", "kind": "interoperability", "answer_data": [ "Target schema identifier, namespace and version", "Aligned element pairs", "Alignment strength such as exact, broader or narrower" ] }, { "id": "q-align-conflicts", "text": "Which semantic conflicts between aligned schemas must be recorded rather than resolved silently?", "kind": "validation", "answer_data": [ "Conflict description and affected elements", "Chosen local semantics", "Loss incurred when projecting outward" ] }, { "id": "q-align-conformance", "text": "On what evidence may conformance to an external schema be claimed?", "kind": "evidence", "answer_data": [ "Conformance test or profile reference", "Test execution date and result", "Scope of the claim and its exclusions" ] }, { "id": "q-align-roundtrip", "text": "Which elements survive a round trip through an external representation and which do not?", "kind": "quality", "answer_data": [ "Round-trip safe element list", "Lossy element list", "Mitigation such as an extension carrier" ] } ], "data_elements": [ { "id": "de-alignment-target", "name": "Alignment Target", "description": "External schema or vocabulary term to which a local element is aligned, with namespace and version.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-alignment-strength", "name": "Alignment Strength", "description": "Declared strength of the mapping between a local element and its external target.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-alignment-conflict", "name": "Alignment Conflict Note", "description": "Recorded semantic conflict arising from an alignment, with the local resolution chosen.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "art-interoperability-binding-profile", "name": "Interoperability Binding Profile", "description": "Published crosswalk profile stating element-by-element mappings between this model and one external interaction schema, with alignment strengths, conflicts and round-trip losses.", "media_or_form": [ "crosswalk mapping table", "profile document", "machine-readable mapping definition" ], "serial": true, "identity_strategy": "Identified by profile name plus target schema namespace and target version, versioned independently of the model and carrying the date its conformance evidence was last executed.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "record-validation-and-exception-handling", "name": "Record Validation and Degraded Capture", "description": "The rules that make an interaction record acceptable, and the explicit handling of partial, delayed, duplicated or unverifiable records so that gaps are visible rather than silently absorbed.", "source_refs": [ "SRC-001", "SRC-004", "SRC-010", "SRC-013" ], "questions": [ { "id": "q-val-minimum-acceptable", "text": "What is the minimum set of assertions for an interaction record to be acceptable?", "kind": "validation", "answer_data": [ "Mandatory element list", "Referential integrity checks", "Consequence of failing validation" ] }, { "id": "q-val-duplicate", "text": "How is a duplicate interaction record detected and reconciled?", "kind": "identity", "answer_data": [ "Duplicate detection keys", "Merge or supersede outcome", "Retention of the withdrawn duplicate" ] }, { "id": "q-val-late-arrival", "text": "How is a turn that arrives out of order or long after the fact incorporated?", "kind": "temporal", "answer_data": [ "Late-arrival marker", "Effect on sequence index and derived measures", "Recomputation obligation" ] }, { "id": "q-val-degraded", "text": "How is a partially captured interaction represented without implying completeness?", "kind": "quality", "answer_data": [ "Completeness indicator", "Known missing element list", "Restriction on evidentiary or reporting use" ] } ], "data_elements": [ { "id": "de-validation-status", "name": "Validation Status", "description": "Result of validating the record against the acceptance rules, with the rule set version applied.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-completeness-indicator", "name": "Completeness Indicator", "description": "Indicator of whether the record is complete, partial or of unknown completeness.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-duplicate-of-ref", "name": "Duplicate Of Reference", "description": "Reference from a withdrawn duplicate to the surviving interaction record.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-late-arrival-flag", "name": "Late Arrival Flag", "description": "Marker that a turn was incorporated after subsequent turns had already been recorded.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Validation outcomes and degradation markers are status values held on the record so that any consumer sees them at the point of use; validation reports and their retention are operational outputs of the adopting Dimension's pipeline rather than context owned by this model." } ] } ] } ] }, "functions": [ { "id": "fn-open-interaction", "name": "Open Interaction", "description": "Create an interaction record with its identity, direction, classification, initial participants and opening time point.", "inputs": [ "Direction code", "Initiating participant reference", "Channel reference", "Interaction reason or category", "Opening time point" ], "outputs": [ "Interaction record with authoritative identifier", "Initial lifecycle status", "Observation time stamped per the timestamp rule" ], "preconditions": [ "The unit-of-account rule confirms no open interaction should absorb this contact", "At least one participant reference resolves in the party model" ], "effects": [ "A new interaction root exists in the opened state", "Correlation keys are registered for later continuation matching" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-010" ] }, { "id": "fn-bind-channel-endpoint", "name": "Bind Channel Endpoint", "description": "Attach a channel and endpoint address binding to a participant for a stated validity period, including any service proxy address.", "inputs": [ "Participant reference", "Channel reference", "Participant endpoint address", "Service proxy address", "Validity start" ], "outputs": [ "Endpoint binding entry with validity period", "Recorded channel capability constraints" ], "preconditions": [ "The participant exists on the interaction", "The address is normalised to its scheme's canonical form" ], "effects": [ "The binding becomes the effective route for subsequent turns on that channel", "Any superseded binding is closed with an end time" ], "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "fn-append-interaction-turn", "name": "Append Interaction Turn", "description": "Record one turn against the interaction with its author, sequence position, channel binding, time points and content references.", "inputs": [ "Interaction identifier", "Author participant reference", "Channel binding reference", "Content part and attachment references", "Authored and received time points" ], "outputs": [ "Turn record with identifier and sequence index", "Retained channel-native identifiers as correlation keys" ], "preconditions": [ "The interaction is in a state that accepts new turns", "The content references resolve or a capture gap is recorded" ], "effects": [ "The turn is placed in canonical order within the interaction", "Derived measures that depend on turn times are marked for recomputation" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-009" ] }, { "id": "fn-resolve-thread-membership", "name": "Resolve Thread Membership", "description": "Compute or reconcile the thread a turn belongs to from identifier chains and asserted relations, recording the method used.", "inputs": [ "Turn identifier", "Reply and reference identifier chain", "Asserted relation, if any", "Derivation method version" ], "outputs": [ "Thread reference for the turn", "Conflict marker where identifier evidence and assertion disagree" ], "preconditions": [ "The turn has been appended", "The derivation method version is declared" ], "effects": [ "Thread membership is recorded as derived or asserted", "Conflicts are surfaced rather than silently resolved" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-009" ] }, { "id": "fn-record-delivery-evidence", "name": "Record Delivery Evidence", "description": "Attach a submission, delivery, failure or engagement outcome to a turn for a specific recipient, with its reporting source and time.", "inputs": [ "Turn identifier", "Recipient participant reference", "Reported outcome code", "Reporting system identifier", "Report time" ], "outputs": [ "Per-recipient delivery evidence entry", "Optional delivery status receipt artifact reference" ], "preconditions": [ "The turn exists and is outbound or has a reporting channel", "Platform acceptance is not recorded as delivery" ], "effects": [ "Delivery state history for the recipient is extended", "Failure reasons and retry outcomes become queryable" ], "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "fn-transition-interaction-state", "name": "Transition Interaction State", "description": "Move the interaction to a new lifecycle state, recording the change time, reason and acting party.", "inputs": [ "Interaction identifier", "Target state", "Status reason", "Acting party reference" ], "outputs": [ "Updated interaction status and status change time", "State transition record" ], "preconditions": [ "The transition is permitted by the transition matrix", "Any guard condition for the target state is satisfied" ], "effects": [ "The interaction status reflects the new state", "Timers bound to the previous state are stopped or started as configured" ], "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "fn-assign-handling-responsibility", "name": "Assign Handling Responsibility", "description": "Set or transfer the party, team or queue accountable for handling the interaction, retaining the prior assignment.", "inputs": [ "Interaction identifier", "New assignee or queue reference", "Transfer reason", "Effective time" ], "outputs": [ "Current assignee reference with effective time", "Assignment history entry for the prior holder" ], "preconditions": [ "The interaction is not in a terminal state, or reassignment after closure is explicitly permitted" ], "effects": [ "Accountability for the interaction moves to the new holder", "Wait and handling duration measures restart per their definitions" ], "source_refs": [ "SRC-001" ] }, { "id": "fn-link-interaction-to-record", "name": "Link Interaction to Record", "description": "Create a typed link from the interaction to a record owned by another model, such as a request, case or subject.", "inputs": [ "Interaction identifier", "Link role code", "Target record reference and referred type" ], "outputs": [ "Typed link entry on the interaction", "Dangling reference marker where the target cannot be resolved" ], "preconditions": [ "The link role exists in the governed role vocabulary", "The target model is identified" ], "effects": [ "The interaction becomes navigable from and to the linked record", "No attribute of the target record is copied into this model" ], "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "fn-record-permission-basis-reference", "name": "Record Permission Basis Reference", "description": "Attach a reference and point-in-time snapshot of the permission decision that authorised an outbound turn, without evaluating permission.", "inputs": [ "Turn identifier", "Permission decision reference", "Basis code and decision version", "Evaluation timestamp reported by the permission model" ], "outputs": [ "Permission basis reference on the turn", "Unresolved-basis marker where no decision reference is supplied" ], "preconditions": [ "The permission decision was produced by the permission model", "Evaluation was performed outside this model" ], "effects": [ "The turn carries evidence of the basis in force at send time", "No permission state is created, changed or evaluated here" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-011" ] }, { "id": "fn-record-revocation-signal", "name": "Record and Hand Off Revocation Signal", "description": "Record a stop, unsubscribe or objection expression observed in a turn and hand it to the permission model, retaining timing evidence.", "inputs": [ "Turn identifier", "Recognised signal type", "Recognition method and version", "Observation time" ], "outputs": [ "Revocation signal observation on the turn", "Handoff reference with acknowledgement and elapsed interval" ], "preconditions": [ "The signal was observed within recorded turn content", "The receiving permission model endpoint is known" ], "effects": [ "The observation and its handoff timing are evidenced on the interaction", "Suppression state itself is created only by the permission model" ], "source_refs": [ "SRC-008", "SRC-011" ] }, { "id": "fn-classify-interaction-confidentiality", "name": "Classify Interaction Confidentiality", "description": "Apply confidentiality, sensitivity and redaction markers to the interaction or its parts and bind them to an access policy identifier.", "inputs": [ "Interaction or part reference", "Classification code", "Sensitivity marker", "Access policy binding identifier", "Authorising party reference" ], "outputs": [ "Classification and redaction markers on the record", "Policy binding reference" ], "preconditions": [ "The classification vocabulary and policy identifier are governed externally" ], "effects": [ "Consumers can see what handling the record requires", "No access decision is evaluated, enforced or logged by this model" ], "source_refs": [ "SRC-002", "SRC-005", "SRC-011" ] }, { "id": "fn-close-interaction-with-outcome", "name": "Close Interaction with Outcome", "description": "Conclude the interaction by recording its outcome, resolution, follow-up commitments and wrap-up note, distinct from its lifecycle status.", "inputs": [ "Interaction identifier", "Outcome code", "Resolution statement", "Follow-up commitments", "Wrap-up note with author and generation method" ], "outputs": [ "Outcome and resolution on the interaction", "Wrap-up note artifact reference", "Closed lifecycle status" ], "preconditions": [ "All turns intended for inclusion have been appended", "Outcome vocabulary values are resolvable" ], "effects": [ "The interaction reaches a terminal state with an explicit outcome", "Retention trigger time is set for the retention model to act on" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-011" ] }, { "id": "fn-issue-disposition-marker", "name": "Issue Disposition Marker", "description": "Bind a retention class, record any hold, and after external execution write the tombstone that shows disposition occurred.", "inputs": [ "Interaction identifier", "Retention class reference", "Retention trigger time", "Hold marker where applicable", "Disposition record reference from the executing model" ], "outputs": [ "Retention class binding and computed earliest disposition date", "Hold marker or its release", "Disposition tombstone" ], "preconditions": [ "The retention schedule is owned by the retention model or adopting Dimension", "Competing obligations have been reconciled to one effective period" ], "effects": [ "The record signals what must happen and when", "Deletion, anonymisation and certification are executed by the owning model, never by this one" ], "source_refs": [ "SRC-008", "SRC-011", "SRC-013" ] } ], "composition": [ { "target": "WM-ACT-018 (parent activity model in NAV.ACT)", "relation": "CHILD", "purpose": "Registers Communication Interaction as a specialisation of the parent activity concept, inheriting generic activity identity and actor structure rather than restating it.", "required": true, "source_refs": [ "SRC-003" ] }, { "target": "Party and party-role model", "relation": "REFERENCE", "purpose": "Participants are carried as party references with a role, mirroring the TMF683 relatedParty pattern; party attributes, identity resolution and lifecycle remain with the party model.", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "Contact point and electronic address registry model", "relation": "REFERENCE", "purpose": "Endpoint bindings cite canonical contact points; address verification, reachability and ownership stay in the registry.", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] }, { "target": "Channel and channel-capability registry model", "relation": "REFERENCE", "purpose": "Channel codes and capability constraints are dereferenced from the channel registry so that channel definitions are not duplicated per interaction.", "required": true, "source_refs": [ "SRC-001", "SRC-012" ] }, { "target": "Permission, consent and preference model", "relation": "REFERENCE", "purpose": "Optional at interaction level. For an outbound turn that requires permission or lawful-basis evidence, carry a resolvable decision reference and point-in-time basis snapshot. Inbound and internal interactions do not invent a permission decision. Capture, evaluation, validity and withdrawal remain owned entirely by the permission model.", "required": false, "source_refs": [ "SRC-007", "SRC-008", "SRC-011" ] }, { "target": "Case, request or service-order model", "relation": "REFERENCE", "purpose": "Provides based-on and part-of links so an interaction can be situated in a wider work item without importing that item's lifecycle.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "Content and media asset model", "relation": "REFERENCE", "purpose": "Attachment and recording bytes, storage location and transcoding are owned by the content model; this model holds references, media types and digests.", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "target": "Records retention and disposition model", "relation": "REFERENCE", "purpose": "Supplies the retention class, schedule and disposition execution; this model contributes only the trigger time, hold marker and tombstone shape.", "required": true, "source_refs": [ "SRC-011", "SRC-013" ] }, { "target": "Access-control and authorization policy model", "relation": "REFERENCE", "purpose": "Consumes the confidentiality and redaction markers carried here; evaluation and enforcement of access requests are never performed by this model.", "required": true, "source_refs": [ "SRC-002", "SRC-005" ] }, { "target": "Audit trail and event log model", "relation": "REFERENCE", "purpose": "Receives access and change events concerning interaction records; FHIR's explicit Communication-versus-AuditEvent split keeps audit-trail semantics outside this boundary.", "required": true, "source_refs": [ "SRC-002" ] }, { "target": "Identifier and reference mixin", "relation": "MIX-IN", "purpose": "Supplies the shared pattern for authoritative identifier, alias retention, superseded-by links and correlation keys used across the interaction root, turns and artifacts.", "required": true, "source_refs": [ "SRC-004", "SRC-009" ] }, { "target": "Temporal expression pattern (RFC 3339 profile)", "relation": "ALIGN", "purpose": "Binds all recorded time points to the RFC 3339 profile including seconds, explicit offset and the unknown-offset convention.", "required": true, "source_refs": [ "SRC-010" ] }, { "target": "TM Forum TMF683 Party Interaction resource", "relation": "ALIGN", "purpose": "Element-level alignment for direction, status, channel, interactionDate, interactionItem, relatedParty, note and interactionRelationship, recorded as alignment with conflicts noted rather than a conformance claim.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "HL7 FHIR Communication resource", "relation": "ALIGN", "purpose": "Alignment for status, category, medium, sender, recipient, sent, received, payload, inResponseTo and about in healthcare-facing deployments, without adopting FHIR's clinical context model.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "W3C Activity Streams 2.0 vocabulary", "relation": "ALIGN", "purpose": "Alignment for actor, object, target, audience targeting and inReplyTo when interactions are projected into social or federated activity feeds.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "Interaction analytics and reporting model", "relation": "EXTEND", "purpose": "Consumes measure definitions and derived durations declared here and extends them into aggregate reporting; aggregation, benchmarking and visualisation are not modelled locally.", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must designate a single accountable owner for the interaction record population and publish the system of record for each channel it operates", "The owner must declare which sibling models supply party, contact point, channel, permission, access, retention and audit semantics before any interaction record is created", "The owner must publish the interaction unit-of-account rule, the continuation window per channel and the lifecycle state transition matrix as versioned governed content", "The owner must maintain a register of channel capability constraints and engagement window rules for every channel in operation" ], "namespace_guidance": "Allocate one namespace per adopting Dimension for locally issued interaction and turn identifiers, kept disjoint from channel-native identifier namespaces which are retained only as correlation keys under their issuing authority's namespace. Vocabulary terms for channel, role, outcome, confidentiality and retention class must be qualified by the owning registry's namespace URI and version so that an unqualified code is never stored.", "registry_links": [ "Vercy registry entry vr.wm-act-027 under nav path NAV.ACT.COM, with parent WM-ACT-018", "Channel and channel-capability registry of the adopting Dimension", "Controlled vocabulary registry for interaction role, category, outcome and confidentiality codes", "External alignment registry recording bound schema namespaces and versions for TMF683, FHIR Communication and Activity Streams 2.0" ] }, "canon_and_patch": { "canonicalization_rules": [ "Serialise interaction records with a deterministic key order and no insignificant whitespace before computing any digest, so that digests are comparable across JSON, YAML and document projections", "Normalise all timestamps to the RFC 3339 profile with seconds and an explicit offset before comparison, preserving the originally reported offset as a separate recorded value", "Normalise endpoint addresses to their scheme's canonical form before correlation, and retain the as-received form alongside the normalised value", "Store vocabulary codes as namespace-qualified pairs of scheme identifier and code, never as bare strings", "Order turns by the monotonic sequence index rather than by timestamp, since author-declared time may precede or follow store-received time" ], "patch_rules": [ "Patches address the interaction root, a named turn, a participant entry or an evidence entry; a patch must never silently rewrite an appended turn's content", "Corrections to already-recorded content are expressed as a replacement turn plus a redaction marker on the original, preserving the superseded record where retention rules require it", "Every patch carries the acting party reference, the reason and the observation time; the change history required for accountability is emitted to the audit model rather than accumulated here", "Lifecycle status, assignment and classification are the only interaction-root fields that may be updated in place; identity, direction and opening time point are immutable after creation", "A patch that would leave a mandatory element unsatisfied is rejected and the record retains its previous validation status" ], "compatibility_rules": [ "Adding an optional element, a new vocabulary value or a new alignment binding is a minor change; removing an element, narrowing cardinality or retyping a value is a breaking change requiring a new major version", "External alignment bindings are versioned independently of this model, so a target schema upgrade does not force a model version change unless local semantics move", "Consumers must tolerate unknown optional elements and unknown vocabulary values, treating the latter as unrecognised rather than invalid", "Deprecated elements remain readable for at least one major version with a superseded-by pointer to their replacement" ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the designated system of record for the interaction, turn or artifact", "Governed global identifier or IRI issued by a recognised external authority, such as an RFC 5322 Message-ID, a Matrix event ID or a platform message identifier retained under its issuing namespace", "UUID or ULID minted by the adopting Dimension when neither a master-system nor a governed global identifier is available" ], "timestamp_rule": "All recorded times use RFC 3339 date-time with seconds and an explicit offset, either Z or a signed hh:mm offset; -00:00 is used only where UTC is known but the local offset is not. Event time and observation or ingestion time are recorded as separate values and never substituted for one another: the author-declared time, the transport or store received time, the delivery report time and this model's own observation time each occupy distinct elements, and where only one is known the others are left absent rather than back-filled.", "serial_naming_rule": "Serial artifacts such as content parts, attachments, delivery receipts, recordings, transcripts and wrap-up notes are named by the owning interaction identifier, the artifact class, and a zero-padded monotonic ordinal within that class, with the issuing system's native identifier retained as a correlation key; ordinals are never reused after a member is withdrawn.", "integrity_rule": "Every retained artifact records a cryptographic digest with its named algorithm and its byte size at capture, plus the capture timestamp and capturing system. Recordings and transcripts subject to a retention obligation must be held on a medium that prevents undetected alteration, and any verification run records its time and result. A digest mismatch marks the artifact unverifiable and downgrades the completeness indicator on the parent interaction rather than deleting the artifact." }, "policies": [ "An interaction record states what was observed and what was referenced; it never asserts a permission decision, an access decision, an audit conclusion or a disposition outcome that another model owns.", "Platform acceptance of a send request is never recorded as delivery, and an engagement signal is never recorded as proof of comprehension or agreement.", "Blind-copied participants and redacted spans are suppressed from redistribution to other participants, and the suppression itself is recorded so the omission is visible to authorised holders.", "Outbound turns must carry a resolvable permission basis reference and, where the applicable regime requires it, the identified sender and a valid cessation route; an unresolved basis is marked, not assumed.", "Partial, late, duplicated or unverifiable records are marked as such and remain visible; silent absorption of gaps into an apparently complete record is prohibited.", "Vocabulary values are stored namespace-qualified and versioned so that a later registry change cannot retroactively alter the meaning of a stored record." ], "crud": { "read": [ "Read of an interaction root, its turns, participants and evidence is mediated by the confidentiality classification carried on the record and evaluated by the access-control model", "Reads that resolve references into party, permission, content or retention models must not cache target attributes into this model's records", "Bulk and analytical reads use the derived measure definitions with an explicit definition version, and must surface the completeness indicator alongside any aggregate", "Read of a tombstoned interaction returns the tombstone and the disposition record reference only" ], "create": [ "Creation requires an authoritative identifier per the identity priority, a direction, at least one participant reference, a channel reference and an observation time", "Creation must first evaluate the unit-of-account and continuation rules so that a contact which should continue an open interaction is appended rather than duplicated", "Turn creation is append-only; a turn is created with its sequence index and channel-native identifiers retained as correlation keys", "Creation records the capturing system, capture method and fidelity level so the record's evidentiary weight is visible from the outset" ], "update": [ "Only lifecycle status, handling assignment, classification and redaction markers, thread membership, evidence entries, outcome and retention markers may be updated in place", "Content corrections are made by appending a replacement turn and marking the original redacted or superseded, never by overwriting recorded content", "Every update records the acting party, reason and observation time, and emits a change event to the audit model which owns the resulting audit trail", "Updates that violate the transition matrix, referential integrity or a mandatory element are rejected and leave the record unchanged" ], "delete": [ "Hard deletion within this model is prohibited by default: an interaction record reaching the end of its retention period is disposed of by the referenced retention and disposition model, or by the adopting Dimension's records policy where no such model is bound, and this model records only the retention class, the retention trigger time and any hold marker", "After the owning model executes disposition, this model retains a tombstone containing the interaction identifier, the retention class reference, the disposition method, the execution timestamp and the reference to the executing model's disposition record; content, attachments, recordings and transcripts are removed by the content and retention models, not here", "A record created in error is withdrawn by transition to an entered-in-error state with a reason, preserving the evidence trail; it is not deleted, and downstream consumers are notified", "A hold marker issued by a competent authority suspends disposition entirely; disposition may resume only after a recorded release, and the longest applicable retention obligation prevails where obligations compete", "Erasure requests arising under data-protection law are routed to the permission and retention models that own the assessment and execution; this model applies only the resulting disposition instruction and records the tombstone" ] }, "roles": [ { "name": "Interaction Record Owner", "responsibilities": [ "Owns the interaction record population and its published unit-of-account, lifecycle and continuation rules", "Designates the system of record per channel and resolves divergence between holders", "Approves model version changes and their compatibility classification" ] }, { "name": "Channel Steward", "responsibilities": [ "Maintains the channel registry entries, capability constraints and engagement window rules used by this model", "Reviews channel-native identifier stability and correlation key quality", "Signals channel deprecation and migration impact on open interactions" ] }, { "name": "Records and Retention Officer", "responsibilities": [ "Binds retention classes and reconciles competing retention obligations to one effective period", "Issues and releases hold markers and confirms tombstone completeness after disposition executed elsewhere", "Verifies that recordings and transcripts subject to obligation are held on a compliant medium" ] }, { "name": "Privacy and Permission Liaison", "responsibilities": [ "Defines the permission basis reference contract between this model and the permission model", "Confirms that revocation signals observed in turns are handed off within the applicable deadline", "Reviews sender identification and cessation route requirements per jurisdiction and channel" ] }, { "name": "Interoperability Steward", "responsibilities": [ "Maintains alignment bindings and interoperability binding profiles with their target schema versions", "Records semantic conflicts and round-trip losses instead of resolving them silently", "Executes and dates conformance evidence before any conformance claim is published" ] }, { "name": "Data Quality Reviewer", "responsibilities": [ "Monitors validation status, duplicate detection, late arrivals and completeness indicators", "Audits capture gaps and fidelity levels against expected coverage", "Escalates systematic capture degradation to the record owner and channel steward" ] } ], "access": { "default_rule": "Deny by default. Access to an interaction record and any of its parts is granted only on an authorization decision made by the referenced access-control model, evaluated against the confidentiality classification, sensitivity markers and access policy binding carried on the record; this model publishes the markers and never performs or caches the decision.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "A participant exercising a right of access to communications concerning them may receive the record subject to suppression of blind-copied participants and of third-party personal data, with the suppression recorded", "A competent authority acting under a recorded legal instrument may be granted access to recordings and transcripts irrespective of ordinary classification, with the instrument reference retained", "Break-glass access in a safety-critical or service-continuity emergency is permitted where the access-control model supports it, subject to mandatory post-hoc review by the record owner", "Aggregate measure access may be granted without content access where the aggregation threshold and completeness indicator are honoured", "Where a channel applies end-to-end encryption and the operator holds no plaintext, access is limited to metadata and this limitation is recorded rather than treated as a denial" ], "audit_requirements": [ "Every access, export and disclosure of an interaction record, artifact or transcript is emitted as an event to the audit model, which owns the audit trail, its immutability and its query semantics", "Break-glass and authority-instrument accesses additionally record the justification and the reviewing party, and are reported to the record owner within the Dimension's stated review interval", "Classification changes, redactions and tombstone writes are emitted with the acting party, prior value and reason", "This model asserts no retention period, immutability guarantee or completeness claim over audit records themselves" ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner or Maintainer", "Model ID and Registry ID", "Version and Compatibility Statement", "Referenced Models and Their Owned Semantics" ], "read_order": [ "AGENTS.md at the model root, to establish Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other access", "The specification at the Specification URL, for scope, boundaries, out-of-scope list and boundary notes", "The storage projection description at the Storage type URL, to learn how the format-neutral semantics are projected into the concrete store, whether that is a document store, a Git tree or a MongoDB collection", "The interface contract at the Interface URL, for the callable surface and its authorization expectations, including MCP tool bindings where used", "The process definitions at the Processes URL, for open, append, evidence, transition, close and disposition-marker procedures", "The referenced-model list, to confirm which semantics are owned elsewhere before reading or writing any field that touches party, permission, access, retention or audit" ] } }, "coverage": { "claim": "Single-provider (Claude) coverage of WM-ACT-027 as an interaction aggregate is internally consistent and source-anchored across identity and correlation, participants and roles, channel and endpoint binding, turns and content, threading and linkage, lifecycle, time and outcome, delivery evidence, provenance and measurement, and the governance references — with ownership of party master data, permission evaluation, access enforcement, audit-trail production, disposition execution and transport mechanics explicitly refused and routed to siblings. This is not a complete account of the subject: per-channel profiles (voice/IMS, RCS Universal Profile, postal), accessibility obligations attaching to channel provision, cross-border transfer conditions, automated-authorship attribution and broadcast/group scaling remain unmodelled; the classification taxonomy rests on convergence across TMF683, FHIR and Activity Streams rather than one governing authority; several functions have no counterpart for participant membership change, record merge/split or recording attachment; and no independent second-provider review exists because Grok was waived by the repository owner.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Authoritative identifier plus retained channel-native identifiers as correlation keys, grounded in RFC 5322 host-guaranteed Message-ID uniqueness, Matrix event IDs and TMF683 id; merge, split and alias retention are explicit." }, { "dimension": "lifecycle", "status": "covered", "notes": "Interaction state machine bound to TMF683 opened/inProgress/completed and FHIR EventStatus including not-done and entered-in-error, with transition matrix, reasons and participant membership lifecycle modelled separately." }, { "dimension": "relationships", "status": "covered", "notes": "Threading via identifier chains and asserted relations, participant-to-party references, and typed links to external records with a dangling-reference policy; target-model attributes are never copied." }, { "dimension": "temporal", "status": "covered", "notes": "Distinct authored, store-received, delivery-report and observation time points under the RFC 3339 profile with seconds and explicit offset, plus interaction periods and channel engagement windows and timers." }, { "dimension": "provenance", "status": "covered", "notes": "Capturing system, capture method, fidelity level, system-of-record precedence and manual-entry marking are first-class, with capture gaps recorded rather than absorbed." }, { "dimension": "ownership", "status": "covered", "notes": "Handling assignment with history is modelled here; record ownership is assigned to a designated owner role, and every externally owned semantic is routed to a composition link." }, { "dimension": "validation", "status": "covered", "notes": "Minimum acceptable assertions, referential integrity, duplicate detection, late arrival and completeness indicators are modelled, with conformance claims requiring dated evidence." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with classification, sensitivity and redaction markers carried locally and evaluation delegated; four scopes and five named exceptions including the encrypted-channel metadata-only case." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention class binding, trigger time, hold markers, conflict precedence and a tombstone shape are modelled; execution is explicitly assigned to the retention model or the adopting Dimension's records policy." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignment bindings to TMF683, FHIR Communication, Activity Streams 2.0, JMAP threading and schema.org Message, with conflicts and round-trip losses recorded and no unevidenced conformance claim." }, { "dimension": "classification", "status": "covered", "notes": "Independent typing dimensions for category, reason, priority, medium and activity verb, each bound to a namespace-qualified governed vocabulary." }, { "dimension": "consent and permission basis", "status": "covered", "notes": "Reference plus point-in-time snapshot only; ePrivacy Article 13 sender identification and cessation route, and 47 CFR 64.1200 revocation recognition, are recorded as observations handed to the permission model." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Delivery receipts as artifacts, engagement signal semantics with confidence qualifiers, recording and transcript integrity, and an explicit rule that acceptance is not delivery." }, { "dimension": "measurement", "status": "covered", "notes": "Measures carry versioned definitions, exclusion rules and a materialisation policy; aggregation and reporting are extended into an analytics model rather than modelled here." }, { "dimension": "security and confidentiality", "status": "covered", "notes": "Classification markers, blind-recipient suppression consistent with the Activity Streams bto/bcc removal requirement, artifact digests and end-to-end encryption implications for stored content." }, { "dimension": "spatial", "status": "not-applicable", "notes": "Location is not intrinsic to a communication interaction; where jurisdiction or local time matters it enters through contact-hours constraints and recording-basis jurisdictions rather than as a geometry element." }, { "dimension": "accessibility and language", "status": "gap", "notes": "Content language tags and machine-translation marking are present, but accessibility obligations for channel provision, such as relay services or accessible formats, are not modelled and no primary source was secured for them." }, { "dimension": "cost and charging", "status": "not-applicable", "notes": "Rating, billing and settlement for communication traffic are explicitly out of scope and belong to a charging model; no local element depends on them." } ], "known_omissions": [ "No channel-specific profile is provided for voice/IMS session semantics, RCS Universal Profile capabilities or postal contact; these would need per-channel extension profiles with their own primary sources.", "Bot, agent-assist and automated-authorship provenance is modelled only as an automation indicator and generation method; detailed model-attribution and disclosure obligations are not developed.", "Accessibility obligations attaching to channel provision are identified as a gap rather than modelled.", "Cross-border transfer conditions for interaction content and recordings are not modelled; they are assumed to be owned by a data-transfer or jurisdiction model.", "Group and broadcast interactions with very large participant counts are supported structurally but no scaling or partitioning guidance is given.", "No primary source was secured for a normative cross-channel interaction taxonomy; the classification dimensions are convergent across TMF683, FHIR and Activity Streams rather than drawn from one authority." ], "conflicts": [ "Lifecycle vocabularies diverge: TMF683 uses opened/inProgress/completed while FHIR binds to EventStatus with preparation, not-done, on-hold, stopped and entered-in-error. The model keeps a local state set with declared alignments rather than adopting either, and records the mapping loss.", "Thread semantics diverge: JMAP computes thread membership from Message-ID/In-Reply-To/References plus subject normalisation, while Matrix uses explicit m.thread relation events. The model supports both and requires the derivation method to be declared, marking conflicts rather than silently preferring one.", "Consent regimes diverge: the ePrivacy Directive requires prior consent with a soft opt-in for similar products, while 47 CFR 64.1200 distinguishes prior express from prior express written consent with a 10-business-day revocation handling period and a 5-year do-not-call honouring period. The model records a reference to whichever decision applied rather than encoding a single regime.", "Delivery semantics diverge: platform acceptance returning a message identifier is explicitly not delivery under the WhatsApp Cloud API, whereas some transports report only submission. The model separates acceptance from delivery evidence, which will read as over-specified against transports that cannot supply the distinction.", "Direction is relative: TMF683 inbound/outbound presumes an enterprise reference point, which does not hold for peer-to-peer or federated interactions. The model requires the reference point to be declared alongside the direction code." ], "regional_assumptions": [ "EU-anchored assumptions from the ePrivacy Directive and GDPR are treated as one regime among several; national implementations of the ePrivacy Directive vary, particularly on soft opt-in and on business-to-business marketing.", "US assumptions from 47 CFR 64.1200 cover federal rules only; state-level restrictions on calling times, consent and recording are not modelled and may be stricter.", "All-party versus one-party recording consent varies by jurisdiction; the model records a recording basis reference and notification evidence but does not encode any jurisdiction's rule.", "MiFID II-style communication recording and five-year retention applies only to in-scope financial services activity and must not be generalised into a default retention class.", "Channel availability, template approval regimes and engagement window durations are platform- and region-specific and are recorded as observed values rather than assumed constants.", "Local time for contact-hours constraints is determined at the recipient's location, which requires a locale or jurisdiction attribution this model references but does not itself resolve." ], "adversarial_checks": [ "Checked every bundle, layer, finding and function against each composition rationale for boundary leakage. Permission evaluation, access enforcement, audit-trail production and disposition execution appear only as references, snapshots, markers or tombstones; fn-record-permission-basis-reference, fn-classify-interaction-confidentiality and fn-issue-disposition-marker each state explicitly that the corresponding evaluation or execution occurs in the target model.", "Tested the temptation to model consent capture locally, since ePrivacy and 47 CFR 64.1200 evidence sits so close to the send event. Rejected: only the decision reference, basis snapshot, sender identification content and observed revocation signal with its handoff timing are retained, because ownership of consent state would duplicate the permission model.", "Tested the temptation to model an audit trail locally, since every update needs accountability. Rejected on the strength of the FHIR statement that Communication is distinct from AuditEvent; change events are emitted outward and this model asserts no immutability or retention guarantee over them.", "Searched for counterexamples to the interaction-as-container assumption. Found two: FHIR Communication is an atomic transfer rather than a container, and a single undelivered outbound message has no exchange at all. Resolved by making granularity an explicit declared code and by requiring an attempt-recording policy rather than assuming a completed exchange.", "Stress-tested identity priority against channels that issue no stable identifier, such as voice calls without a platform reference. Confirmed the third tier of the identity priority applies, and required the capture method and fidelity level to be recorded so that a locally minted identifier is never mistaken for external authority.", "Checked whether any structural node lacks primary support. The interaction taxonomy rests on convergence across three standards rather than one authority and is flagged as a gap in the checklist; accessibility is flagged as an outright gap rather than presented with invented support.", "Verified that the known-relation ledger supplied with this task is empty, so all composition links are proposed rather than confirmed; each is nonetheless justified by a cited source and none grants this model a target's lifecycle or operational semantics." ] }, "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": "The frozen registry record carries entry_kind 'standalone-mm' with review_state 'boundary-review-required', while the active-provider result declares 'aggregate'. The aggregate reading is the better-supported one on this evidence: turns, content parts, attachments, delivery receipts, wrap-up notes, recordings and transcripts have no identity outside the interaction root, only the root carries an authoritative external identifier, and every externally owned semantic (party, permission, access, audit, retention execution, transport) is expressed as a typed reference, snapshot, marker or tombstone rather than as local state. Split was tested twice and rejected: recording-and-transcript-material is evidence of the same exchange rather than an independent asset lifecycle, and interaction-measurement, though the thinnest node, derives entirely from time points owned here. Merge was not tested because the relationship ledger is empty. The plan therefore carries 'aggregate' forward as a reclassification relative to the frozen value, and the registry record must be reconciled — entry_kind updated or the two vocabularies explicitly distinguished — before this leaves reviewable-draft state." }, "decisions": [ { "concept": "Aggregate root is the interaction record containing ordered turns", "disposition": "accepted", "rationale": "Turns, content parts, attachments, delivery receipts and wrap-up notes have no identity or lifecycle outside the root, and TMF683, FHIR Communication and JMAP all supply root-plus-parts structure. The root is the only element the model gives a stable authoritative identifier, which is the correct aggregate-boundary test." }, { "concept": "Interaction-as-container versus FHIR's atomic transfer, resolved by a declared granularity code", "disposition": "accepted with constraint", "rationale": "The provider's own adversarial check found two genuine counterexamples and resolved them with a declared granularity code. That preserves both readings but makes cross-adopter comparability conditional on the code. The synthesizer must emit granularity as a required root-level assertion with a stated default, not an optional profile switch, or two adopters will produce structurally incomparable records under one model id." }, { "concept": "Entry kind mismatch between frozen registry ('standalone-mm') and result ('aggregate')", "disposition": "reclassified to aggregate, registry reconciliation required", "rationale": "The mismatch is unresolved in the evidence pack and the registry itself flags boundary-review-required. Carrying 'aggregate' forward is defensible on composition evidence, but the divergence must be visible in the draft rather than silently normalised by the synthesizer." }, { "concept": "art-turn-attachment and art-interaction-media-recording custody versus the content-model boundary note", "disposition": "accepted as reference-with-digest artifacts, custody statement required", "rationale": "The boundary note states attachment bytes, transcoding and storage location are owned by the content model and this record carries references, media type and digests, yet both are declared as artifacts of this model with byte-level media forms. Without an explicit custody statement the artifact declaration reads as a claim on storage the scope statement disclaims." }, { "concept": "q-meas-storage — are measures materialised or recomputed on demand", "disposition": "rejected as written, reframe as derivation provenance", "rationale": "The scope statement declares the model storage- and interface-neutral, so a materialisation question is an implementation policy leak. The retainable content is whether a measure is asserted or derived and against which versioned definition, which is a provenance question the model already supports elsewhere." }, { "concept": "Channel capability constraints held locally alongside a sibling channel registry", "disposition": "accepted, narrowed to values observed at turn time", "rationale": "Recording what was sendable explains the turn and belongs here, but message-size, media-type and template rules are registry semantics. Narrowing to observed-at-turn values keeps this model from becoming a second, drifting capability registry." }, { "concept": "Permission evaluation excluded; only decision reference plus point-in-time snapshot retained", "disposition": "accepted", "rationale": "ePrivacy and 47 CFR 64.1200 place consent capture, validity and revocation with the permission holder. The provider tested the temptation to model capture locally and rejected it, and the retained snapshot, sender-identification content and observed revocation signal are the minimum needed to explain the send without owning consent state." }, { "concept": "Blind-copy suppression as a visibility marker rather than enforcement behaviour", "disposition": "accepted with constraint", "rationale": "The Activity Streams bto/bcc removal requirement is a rendering obligation, and this model disclaims enforcement. The citation must be carried as marker semantics with enforcement routed to the access model, otherwise the security checklist entry reads as an enforcement claim the boundary refuses." }, { "concept": "Retention expressed as class binding, trigger, hold marker and tombstone only", "disposition": "accepted", "rationale": "MiFID II fixed retention is sector-specific and the regional assumptions already forbid generalising it into a default class. Schedule, disposition decision, execution and certification stay with the retention model, and the tombstone is the correct residue for a record whose deletion is executed elsewhere." }, { "concept": "Handling assignment owned here while workforce management and routing are out of scope", "disposition": "accepted", "rationale": "The current responsibility holder and its transfer history are interaction state, not scheduling logic. The line holds as long as the model records only the resulting holder as a typed reference with change times and never queue definitions or routing rules." }, { "concept": "Function-set coverage gaps against declared findings and questions", "disposition": "deferred to next revision, not repaired here", "rationale": "participant-membership-lifecycle has no membership-change function, q-id-merge-split has no merge or split function, and art-interaction-media-recording and art-interaction-transcript have no attaching function. These are real coverage gaps, but add_functions must remain empty in single-provider mode, so they are recorded rather than filled." }, { "concept": "Source-reference drift between functions and their findings", "disposition": "flagged for correction before promotion", "rationale": "fn-close-interaction-with-outcome cites SRC-011 while its finding outcome-and-wrap-up-record cites only SRC-001 and SRC-002, and fn-record-revocation-signal omits SRC-007 which its finding carries. Function citations must not exceed or fall short of the support their findings establish." }, { "concept": "Permission-reference requiredness", "disposition": "accepted as conditional reference", "rationale": "A communication interaction may be inbound, internal or otherwise outside a consent-based outbound-contact path. Therefore the composition reference is optional at aggregate level. When an outbound turn requires permission or lawful-basis evidence, the applicable profile requires a resolvable permission-decision reference and point-in-time snapshot; the interaction never evaluates or owns permission state." } ], "publicationHolds": [ "Single-provider hold: Grok was waived by the repository owner at 2026-08-29T09:06:27Z after repeated structured-output failures, so no independent second-provider review of this result exists. The result stays a reviewable draft and every publication artifact must carry the waiver, its authorising party, its timestamp and the statement that structure, entry kind and boundary rest on one provider plus this no-tools adversarial audit.", "Live source and version verification hold: none of the 13 URLs were re-fetched during this audit. Before promotion each must be resolved live and pinned, with specific attention to SRC-005 (Matrix pinned to a floating 'latest', v1.19 at access), SRC-008 (Cornell LII reproduction rather than the official eCFR or FCC text, tier 2, non-primary, yet carrying permission, engagement-window and retention load), SRC-012 (undated vendor documentation, tier 3, carrying the acceptance-is-not-delivery rule and engagement windows) and SRC-011 (pointer to a 2016-05-04 consolidation whose currency must be re-checked).", "Registry and relationship reconciliation hold: the frozen record declares entry_kind 'standalone-mm' with review_state 'boundary-review-required' against a declared 'aggregate', and the relationship contract is empty, so the parent link to WM-ACT-018 and every composition link remain proposed rather than confirmed. Publication must state that no composition relation has been ratified.", "Artifact custody hold: art-turn-attachment, art-interaction-media-recording and art-interaction-transcript are declared with byte-level media forms while the boundary note assigns attachment bytes, transcoding and storage to the content model. Each artifact entry must carry an explicit custody statement (referenced with digest versus held here) before publication.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Re-pin the weak citations: replace SRC-008 with the official eCFR or FCC text, fix SRC-005 to an immutable Matrix specification version rather than 'latest', date SRC-012 or replace it, and re-verify the SRC-011 consolidation currency.", "Secure a non-vendor, standards-track source for the acceptance-is-not-delivery distinction, which currently rests structurally on tier-3 WhatsApp Cloud API documentation and is acknowledged as over-specified against transports that cannot supply the distinction.", "Obtain an independent structural review — successor second provider or human boundary reviewer — of the aggregate-root granularity code, since the interaction-versus-atomic-transfer resolution rests on a single provider's judgement with no cross-check.", "Close the function-coverage gaps identified here: participant membership change, interaction record merge and split, and attachment of recording and transcript material, each with its own source support.", "Locate a normative cross-channel interaction taxonomy so the classification dimensions can rest on a governing authority rather than convergence across TMF683, FHIR and Activity Streams, as the provider's own checklist flags.", "Model the declared gaps that remain unsourced: accessibility obligations attaching to channel provision, cross-border transfer conditions for interaction content and recordings, automated-authorship attribution and disclosure, and scaling guidance for large group or broadcast interactions.", "Ratify the parent relation to WM-ACT-018 and the proposed composition links in the relationship ledger so the ownership boundary moves from asserted to confirmed." ] }, "statistics": { "sources": 13, "bundles": 6, "layers": 15, "findings": 27, "questions": 104, "artifacts": 7, "functions": 13 } }