# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-24T18:41:18Z", "synthesisSha256": "7c5071e5e5c86f4758dd56fbca33ba4dc858b6c6bd51c507f97d5939ae2e0d7f", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-REC-003", "registryId": "vr.wm-rec-003", "name": "Message", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.REC.MSG" ], "tags": [ "message", "inf.rec.msg" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-rec-003-message/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-rec-003", "model": { "registry_id": "vr.wm-rec-003", "model_id": "WM-REC-003", "name": "Message", "entry_kind": "aggregate", "purpose": "Provide the format-neutral context an agent needs to compose, address, send, carry, evidence, govern and interpret a discrete communication between agents across any channel.", "scope_statement": "A Message is a discrete, addressed communication act and its record: an originator releases identified content to one or more recipient endpoints over a channel, producing handling, delivery and disposition evidence. The model is an aggregate whose root is the message record and whose parts are content parts, addressing entries, handling-trace entries and evidence records. It is channel-neutral: electronic mail (RFC 5322/5321), instant messaging (RFC 6121), federated social activity (ActivityStreams 2.0), machine/event messaging (MQTT 5.0, CloudEvents), room-based messaging (Matrix) and clinical/business communication (FHIR Communication) are all projections of the same act. Storage and interface (JSON, YAML, Markdown, Git, MCP, MongoDB) are projections, not semantics.", "in_scope": [ "Message identity, classification, content parts, media typing and carriage of attachments or structured payloads", "Originator and recipient roles, addressing visibility, recipient resolution, envelope-versus-content separation and handling trace", "Conversation threading, reply and reference chains, derived/redistributed messages and request-response correlation", "Transmission state, time points, delivery status records, registered delivery evidence and duplicate control", "Origin authentication assertions, confidentiality/integrity protection scope and tamper evidence", "Permission basis asserted at send time, opt-out signals, retention and disposition, redaction/deletion and access to retained copies" ], "out_of_scope": [ "The intrinsic content model, versioning and lifecycle of a carried document or dataset — the message owns only the carriage relation", "The party/agent entity itself (person, organization, software agent) and its attributes", "The durable contact-endpoint registry and address-scheme governance (owner, verification state, scheme syntax rules)", "The standing consent/permission record about a subject and purpose, including its own grant/withdraw lifecycle", "Channel-provider service entities, contracts, credentials, MTA/broker configuration and network operation", "Cryptographic key material, trust anchors and certificate lifecycle management", "Human language, terminology and translation semantics of message text" ], "boundary_notes": [ { "neighbor": "Document and record model (carried payloads)", "distinction": "MIME defines a body part and a Content-ID within the message entity, and FHIR Communication.payload is either inline content or a reference to a separately governed resource. The message therefore owns part structure, media typing, filename/disposition and payload digest, but not the referenced document's own identity, version history or retention rule.", "source_refs": [ "SRC-003", "SRC-016" ] }, { "neighbor": "Contact endpoint and identifier-scheme model", "distinction": "RFC 5321 gives a mailbox meaning only inside SMTP; XMPP gives a JID meaning only inside XMPP; MQTT topics are broker-scoped. The message owns the addressing entry (role, submitted value, resolved value) as it existed for this message; the durable endpoint entity, its owner and its verification state belong to a sibling model.", "source_refs": [ "SRC-002", "SRC-008", "SRC-017" ] }, { "neighbor": "Consent and permission model", "distinction": "ePrivacy Article 13 and GDPR Article 7 make consent a record about a subject, purpose and channel with its own demonstrability and withdrawal lifecycle, independent of any message. The message model records only the permission basis cited at send time and the opt-out signals the message itself carries (RFC 8058 List-Unsubscribe-Post).", "source_refs": [ "SRC-014", "SRC-015", "SRC-009" ] }, { "neighbor": "Event/activity model", "distinction": "CloudEvents describes an occurrence with source+id uniqueness and no inherent addressee; a message is directed to identified recipients and carries delivery obligation. An event becomes in-scope only when it is transported as an addressed message.", "source_refs": [ "SRC-018", "SRC-010" ] }, { "neighbor": "Delivery-evidence trust service", "distinction": "eIDAS Articles 43-44 attach legal presumptions only to a qualified electronic registered delivery service. The message model records the evidence object and its issuer, but conformity assessment and qualified status of the provider are governed elsewhere and must not be inferred from the presence of an evidence record.", "source_refs": [ "SRC-013", "SRC-021" ] }, { "neighbor": "Records retention schedule model", "distinction": "NARA GRS 6.1 / Capstone assigns disposition by role and schedule item, which is an organizational instrument. The message model holds the applied disposition instruction reference and executed disposition events, not the schedule itself.", "source_refs": [ "SRC-020", "SRC-015" ] } ] }, "sources": [ { "id": "SRC-001", "title": "RFC 5322: Internet Message Format", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5322.html", "version_or_date": "October 2008, Standards Track (obsoletes RFC 2822)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:05:00Z", "relevance": "Normative message identity (Message-ID MUST be unique), origination date, originator/destination/identification/informational/resent/trace field families." }, { "id": "SRC-002", "title": "RFC 5321: Simple Mail Transfer Protocol", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5321.html", "version_or_date": "October 2008, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:07:00Z", "relevance": "Envelope (reverse-path/forward-path) versus content separation, Received trace obligations for relays, and null reverse-path for undeliverable-mail notifications." }, { "id": "SRC-003", "title": "RFC 2045: MIME Part One — Format of Internet Message Bodies", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc2045.html", "version_or_date": "November 1996, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:08:00Z", "relevance": "MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID and Content-Description; recursive multipart entity structure and part-level media typing." }, { "id": "SRC-004", "title": "RFC 3464: An Extensible Message Format for Delivery Status Notifications", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3464.html", "version_or_date": "January 2003, Standards Track (obsoletes RFC 1894)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:10:00Z", "relevance": "Per-message (Original-Envelope-Id, Reporting-MTA, Arrival-Date) and per-recipient (Original-Recipient, Final-Recipient, Action, Status, Diagnostic-Code, Last-Attempt-Date) delivery evidence fields." }, { "id": "SRC-005", "title": "RFC 8098: Message Disposition Notification", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc8098.html", "version_or_date": "February 2017, Internet Standard STD 85 (obsoletes RFC 3798)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:12:00Z", "relevance": "Disposition types and modes, Original-Message-ID/Original-Recipient/Final-Recipient correlation, and the explicit warning that MDNs do not provide non-repudiation and can be forged or lost." }, { "id": "SRC-006", "title": "RFC 8601: Message Header Field for Indicating Message Authentication Status", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc8601.html", "version_or_date": "May 2019, Standards Track (obsoletes RFC 7601)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:14:00Z", "relevance": "Authentication-Results semantics: authserv-id, methods (dkim, spf, dmarc, iprev, auth), result vocabulary, and the ADMD trust-boundary rule requiring deletion of untrusted instances." }, { "id": "SRC-007", "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": "July 2002, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:15:00Z", "relevance": "Mandatory explicit offset or Z, the -00:00 unknown-local-offset convention, and leap-second handling for all message time points." }, { "id": "SRC-008", "title": "RFC 6121: XMPP — Instant Messaging and Presence", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6121.html", "version_or_date": "March 2011, Standards Track (obsoletes RFC 3921)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:17:00Z", "relevance": "Non-email evidence for message typing (normal/chat/groupchat/headline/error), thread element with parent attribute, stanza id correlation and subscription-based contactability." }, { "id": "SRC-009", "title": "RFC 8058: Signaling One-Click Functionality for List Email Headers", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc8058.html", "version_or_date": "January 2017, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:19:00Z", "relevance": "Message-carried opt-out: List-Unsubscribe-Post one-click semantics, HTTPS URI constraint, DKIM-signature coverage requirement and receiver consent obligation." }, { "id": "SRC-010", "title": "Activity Vocabulary (ActivityStreams 2.0)", "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-24T09:21:00Z", "relevance": "Channel-neutral actor/object/target and to/bto/cc/bcc/audience addressing, the normative requirement that intermediaries MUST remove bto and bcc, inReplyTo, context, attachment and mediaType." }, { "id": "SRC-011", "title": "Message Headers — Permanent Message Header Field Names registry", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/message-headers/message-headers.xhtml", "version_or_date": "Registry, last updated 2026-05-13", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:23:00Z", "relevance": "Authoritative controlled vocabulary of message header field names with status (standard/informational/obsoleted), the correct governance point for extension metadata rather than local invention." }, { "id": "SRC-012", "title": "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml", "version_or_date": "Registry, last updated 2024-12-06 (per RFC 5248, codes per RFC 3463)", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:24:00Z", "relevance": "Class/subject/detail structure of delivery outcome codes: 2.x.x success, 4.x.x persistent transient failure, 5.x.x permanent failure — the basis for a channel-neutral outcome classifier." }, { "id": "SRC-013", "title": "Regulation (EU) No 910/2014 (eIDAS) — Articles 3(36)-(37), 43, 44", "organization": "European Union (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910", "version_or_date": "Regulation of 23 July 2014", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:27:00Z", "relevance": "Legal definition of electronic registered delivery service and the rebuttable presumptions of integrity, sending, receipt and accuracy of date and time attaching only to qualified services." }, { "id": "SRC-014", "title": "Directive 2002/58/EC on privacy and electronic communications — Articles 5, 6, 9, 13", "organization": "European Union (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32002L0058", "version_or_date": "Directive of 12 July 2002 (as amended by Directive 2009/136/EC)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:29:00Z", "relevance": "Prior-consent rule for direct-marketing electronic mail, the soft opt-in exception, the ban on concealing sender identity or omitting a valid opt-out address, confidentiality of communications and traffic-data erasure." }, { "id": "SRC-015", "title": "Regulation (EU) 2016/679 (GDPR) — Articles 4(11), 5(1)(e), 7, 21, 30", "organization": "European Union (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679", "version_or_date": "Regulation of 27 April 2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:31:00Z", "relevance": "Consent definition and demonstrability, withdrawal parity, storage limitation, right to object to direct marketing and records of processing — governing constraints on message retention and permission evidence." }, { "id": "SRC-016", "title": "FHIR R5 Communication resource", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/communication.html", "version_or_date": "FHIR v5.0.0 (Release 5), Standard for Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:33:00Z", "relevance": "Cross-domain confirmation of a channel-neutral message record: status/statusReason, category, priority, medium, topic/about, sent/received, sender/recipient, payload, inResponseTo, basedOn/partOf, and the executed-versus-requested boundary." }, { "id": "SRC-017", "title": "MQTT Version 5.0", "organization": "OASIS", "url": "https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html", "version_or_date": "OASIS Standard, 07 March 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:35:00Z", "relevance": "Machine-messaging delivery guarantees (QoS 0/1/2 = at most once / at least once / exactly once), Message Expiry Interval, retained messages, Payload Format Indicator, Content Type, Correlation Data and Response Topic." }, { "id": "SRC-018", "title": "CloudEvents Specification v1.0.2", "organization": "Cloud Native Computing Foundation (CNCF) Serverless Working Group", "url": "https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md", "version_or_date": "v1.0.2", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:37:00Z", "relevance": "Composite identity rule (producers MUST ensure source+id uniqueness), datacontenttype/dataschema/subject typing of structured payloads and the RFC 3339 requirement on time." }, { "id": "SRC-019", "title": "Matrix Specification v1.16 — Client-Server API", "organization": "The Matrix.org Foundation C.I.C.", "url": "https://spec.matrix.org/v1.16/client-server-api/", "version_or_date": "Specification v1.16", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:39:00Z", "relevance": "Event-graph messaging: event_id/sender/origin_server_ts/room_id/content, m.relates_to reply and thread relations, msgtypes, read receipts, and redaction semantics that preserve structural fields while removing content." }, { "id": "SRC-020", "title": "Email and Electronic Messages Management (Capstone, GRS 6.1, Bulletin 2023-02)", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/email-mgmt", "version_or_date": "Guidance page, last reviewed 29 September 2025", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:41:00Z", "relevance": "Public-authority evidence that message disposition can be assigned by originator role rather than per-item review, and that electronic messages are scheduled records under 44 U.S.C. ch. 29 and 36 CFR ch. XII." }, { "id": "SRC-021", "title": "ETSI EN 319 522-2: Electronic Registered Delivery Services; Part 2: Semantic contents", "organization": "European Telecommunications Standards Institute (ETSI)", "url": "https://www.etsi.org/deliver/etsi_en/319500_319599/31952202/01.02.00_20/en_31952202v010200a.pdf", "version_or_date": "V1.2.0 draft / V1.1.1 (2018-09)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:43:00Z", "relevance": "Named ERDS evidence set (SubmissionAcceptanceRejection, RelayAcceptanceRejection, NotificationForAcceptance, ConsignmentAcceptanceRejection, ContentConsignment, RetrievalNonRetrieval, DeliveryExpiration) and mandatory evidence components. NOTE: direct retrieval returned HTTP 403; content corroborated via ETSI abstracts and eIDAS Art. 43 — treated as a gap-flagged alignment, not verified conformance." }, { "id": "SRC-022", "title": "Activity Streams 2.0", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/activitystreams-core/", "version_or_date": "W3C Recommendation 23 May 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:10:00Z", "relevance": "Normative social object model: id IRI, attributedTo, to/bto/cc/bcc/audience, inReplyTo, published/updated, attachment, mediaType, natural-language maps, RFC 3339 timestamps, collections." }, { "id": "SRC-023", "title": "ActivityPub", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/activitypub/", "version_or_date": "W3C Recommendation 23 January 2018", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:40:00Z", "relevance": "Normative federation: actor inbox and outbox, addressing and delivery, Create wrapping, Update, Delete/Tombstone, Undo, Block, sharedInbox, transient objects without id, inbox forwarding for ghost replies." }, { "id": "SRC-024", "title": "FHIR Resource Communication R5", "organization": "HL7 International", "url": "https://www.hl7.org/fhir/communication.html", "version_or_date": "FHIR v5.0.0, 26 March 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:50:00Z", "relevance": "Clinical or business record of information being transmitted, including planned and failed attempts. Status, medium, sent/received, payload, inResponseTo, sender, recipient. Distinct from AuditEvent and Encounter." }, { "id": "SRC-025", "title": "Art. 7 GDPR Conditions for consent", "organization": "European Union", "url": "https://gdpr-info.eu/art-7-gdpr/", "version_or_date": "Regulation (EU) 2016/679, 27 April 2016; article page retrieved 2026-08-24", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Live retrieval of GDPR Article 7 text: demonstrable consent, distinguishable request, withdrawal as easy as grant, withdrawal does not undo prior lawful processing. Authentic instrument is CELEX:32016R0679. Secondary presenter is gdpr-info.eu." } ], "structure": { "bundles": [ { "id": "content-and-payload", "name": "Content and Payload", "description": "What the message says and carries: its identity, classification, part structure, media typing and carried payloads.", "rationale": "RFC 5322 separates the header section from the body, and MIME makes the body a recursive structure of typed entities; FHIR and CloudEvents confirm the same split between a communication record and its typed payload. Content is therefore a bundle distinct from addressing and from transit evidence.", "source_refs": [ "SRC-001", "SRC-003", "SRC-016", "SRC-018" ], "layers": [ { "id": "message-core-and-classification", "name": "Message Core and Classification", "description": "The identity of the message as a record and the classifiers that govern how it must be handled.", "source_refs": [ "SRC-001", "SRC-016", "SRC-018" ], "findings": [ { "id": "message-identity", "name": "Message identity and identifier provenance", "description": "A message needs one durable identifier whose generator and uniqueness guarantee are known, plus any secondary identifiers assigned by transport or by the adopting Dimension. RFC 5322 requires the generator to guarantee msg-id uniqueness; CloudEvents requires source+id uniqueness; Matrix assigns a server-side event_id; SMTP separately carries an envelope identifier. These are different identifiers with different guarantors and must not be conflated.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-018", "SRC-019" ], "questions": [ { "id": "q-msg-id-authority", "text": "Which system generated the message's primary identifier and what is its uniqueness guarantee and scope?", "kind": "identity", "answer_data": [ "identifier value", "generating system or domain", "uniqueness scope (global, source-scoped, room-scoped)", "identifier syntax or scheme reference" ] }, { "id": "q-msg-id-composite", "text": "Is identity single-valued or composite, and if composite which attributes form the key?", "kind": "identity", "answer_data": [ "composite key components (e.g. source + id)", "reason for compositeness", "collision-resolution rule" ] }, { "id": "q-msg-id-secondary", "text": "Which secondary identifiers exist for this message and who assigned each one?", "kind": "provenance", "answer_data": [ "identifier value", "assigning role (originator, submission agent, relay, store)", "assignment time (RFC 3339)", "binding strength (authoritative, advisory)" ] }, { "id": "q-msg-id-copies", "text": "Does each recipient copy carry the same identifier, and how is a copy distinguished from the original record?", "kind": "identity", "answer_data": [ "copy identifier", "custodian reference", "relation to originator record" ] } ], "data_elements": [ { "id": "de-message-id", "name": "messageIdentifier", "description": "Primary identifier of the message as generated by the originating system, in the syntax of the governing channel standard.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-018" ] }, { "id": "de-id-scope", "name": "identifierScope", "description": "Scope within which the identifier is guaranteed unique (global, source-scoped, room-scoped, submission-scoped).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-018", "SRC-019" ] }, { "id": "de-envelope-id", "name": "envelopeIdentifier", "description": "Transport-assigned submission identifier used to correlate status reports with a submission transaction, distinct from the content identifier.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "de-alt-ids", "name": "alternateIdentifiers", "description": "Additional identifiers assigned by stores, relays or the adopting Dimension, each with its assigner.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-004" ] } ], "artifacts": [ { "id": "message-record", "name": "Message record", "description": "The aggregate root: the persisted representation of one communication act, binding identity, classification, content parts, addressing entries and evidence references.", "media_or_form": [ "structured record", "serialized message entity", "header section plus body" ], "serial": false, "identity_strategy": "Authoritative master-system message identifier from the originating channel (msg-id, event_id, broker-assigned id); otherwise a governed composite of source and id; otherwise a UUID or ULID assigned by the adopting Dimension, never a timestamp.", "source_refs": [ "SRC-001", "SRC-018", "SRC-019" ] } ], "inline_only_rationale": null }, { "id": "subject-classification-and-priority", "name": "Subject, classification, priority and sensitivity", "description": "Classifiers that drive handling: topic/subject, functional category, urgency and sensitivity. FHIR distinguishes category, priority, topic and about; XMPP types a stanza as chat, groupchat, headline, normal or error; ActivityStreams types the activity itself. These are separate axes and collapsing them loses handling semantics.", "source_refs": [ "SRC-001", "SRC-008", "SRC-010", "SRC-016", "SRC-011" ], "questions": [ { "id": "q-cls-axes", "text": "Which classification axes apply to this message and which are mandatory for the channel?", "kind": "classification", "answer_data": [ "axis name", "code value", "code system or registry reference", "obligation (required, conditional, optional)" ] }, { "id": "q-cls-priority", "text": "What urgency or priority is asserted, by whom, and does it change handling or retention?", "kind": "classification", "answer_data": [ "priority code", "asserting role", "handling effect" ] }, { "id": "q-cls-sensitivity", "text": "What sensitivity or confidentiality label applies and what handling constraint does it impose?", "kind": "security", "answer_data": [ "sensitivity label", "labelling authority", "permitted handling actions", "redistribution restriction" ] }, { "id": "q-cls-topic", "text": "How is the human-readable subject distinguished from the machine-resolvable topic or about-reference?", "kind": "definition", "answer_data": [ "subject text", "topic code", "about reference", "language tag" ] } ], "data_elements": [ { "id": "de-subject", "name": "subjectText", "description": "Human-readable subject or summary of the message.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "de-category", "name": "messageCategory", "description": "Functional category of the communication (alert, notification, reminder, chat, headline, instruction).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-008" ] }, { "id": "de-priority", "name": "priority", "description": "Asserted urgency of the message from a governed code list.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-sensitivity", "name": "sensitivityLabel", "description": "Confidentiality or sensitivity classification constraining handling and redistribution.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Classifiers are attributes of the message record rather than separately custodied objects; they have no independent identity, no separate custodian and are never transmitted or retained apart from the message. The governed code lists they draw on belong to a classification/registry sibling model." }, { "id": "channel-type-and-medium", "name": "Channel type and provider", "description": "A channel is the transport medium used or intended, not the message. RFC 5321 defines SMTP client, server, relay, gateway, originating and delivery systems. ActivityPub uses inbox and outbox OrderedCollections and optional sharedInbox. FHIR Communication.medium records how the communication was conveyed. Gatewaying may transform headers and envelopes in ways forbidden to a pure relay. Channel type is classification here; credentials and live sockets are out of scope.", "source_refs": [ "SRC-002", "SRC-023", "SRC-024" ], "inline_only_rationale": null, "questions": [ { "id": "channel-type-and-medium-q01", "text": "Which channel type and provider actually carried this message, and was the hop an origin, relay, gateway or delivery system?", "kind": "classification", "answer_data": [ "channel-type, provider-ref, hop-role enum origin | relay | gateway | delivery, protocol-profile." ] }, { "id": "channel-type-and-medium-q02", "text": "If federated social transport, which outbox accepted the activity and which inbox or sharedInbox was posted?", "kind": "process", "answer_data": [ "outbox-iri, inbox-iri, shared-inbox-iri, posted-at." ] }, { "id": "channel-type-and-medium-q03", "text": "If a clinical communication, what medium codes describe how information was shared?", "kind": "classification", "answer_data": [ "List of FHIR medium CodeableConcepts with system and code." ] } ], "data_elements": [ { "id": "channel-type-and-medium-data01", "name": "channel-type", "description": "smtp | submission | activitypub-inbox | fhir-medium | imap-store | xmpp | matrix | sms | postal | broadcast | other.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-023", "SRC-024" ] }, { "id": "channel-type-and-medium-data02", "name": "provider-ref", "description": "Organization or service that operates the channel.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "channel-type-and-medium-data03", "name": "protocol-profile", "description": "EHLO extensions, ActivityPub c2s vs s2s, FHIR medium coding.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-023", "SRC-024" ] }, { "id": "channel-type-and-medium-data04", "name": "gatewayed-from-channel", "description": "Prior channel if this copy was gatewayed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "channel-type-and-medium-data05", "name": "shared-inbox-iri", "description": "ActivityPub sharedInbox used for public or followers delivery.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] } ], "artifacts": [ { "id": "channel-type-and-medium-artifact01", "name": "channel-descriptor", "description": "Channel type, provider, protocol profile and whether this hop is origin, relay, gateway or delivery.", "media_or_form": [ "structured record" ], "serial": false, "identity_strategy": "Per the model identifier priority: authoritative origin identifier (Message-ID, ActivityPub object id IRI or FHIR identifier), else a governed global IRI, else a Dimension-assigned UUID or ULID; a date is never an identifier.", "source_refs": [ "SRC-002", "SRC-023", "SRC-024" ] } ] } ] }, { "id": "content-structure-and-payload", "name": "Content Structure and Payload", "description": "The recursive part structure of message content, its media typing, and the payloads it carries by value or by reference.", "source_refs": [ "SRC-003", "SRC-016", "SRC-017", "SRC-018" ], "findings": [ { "id": "body-parts-and-media-typing", "name": "Body parts, media typing and alternative representations", "description": "MIME makes a message body a recursive tree of entities, each with its own Content-Type, transfer encoding, Content-ID and optional description; MQTT types payload with a Payload Format Indicator and Content Type; Matrix types content by msgtype. Interpretation requires knowing the part tree, the declared type of each node and which sibling parts are alternatives rather than additions.", "source_refs": [ "SRC-003", "SRC-017", "SRC-019", "SRC-010" ], "questions": [ { "id": "q-part-tree", "text": "What is the ordered part tree of this message and what is the structural role of each node?", "kind": "composition", "answer_data": [ "part path or index", "parent part reference", "structural role (alternative, mixed, related, signed, encrypted)" ] }, { "id": "q-part-type", "text": "What media type, subtype, parameters and transfer encoding are declared for each part, and were they verified against the octets?", "kind": "validation", "answer_data": [ "media type and parameters", "declared transfer encoding", "verification outcome", "verifying agent" ] }, { "id": "q-part-alt", "text": "Which part is the canonical representation when several alternatives express the same content?", "kind": "decision", "answer_data": [ "canonical part reference", "selection rule", "fallback order" ] }, { "id": "q-part-lang", "text": "What natural language and character encoding apply to each textual part?", "kind": "interoperability", "answer_data": [ "language tag", "charset parameter", "directionality" ] } ], "data_elements": [ { "id": "de-part-path", "name": "partPath", "description": "Position of the part within the recursive content tree.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-part-mediatype", "name": "partMediaType", "description": "Declared media type, subtype and parameters of the part.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-017" ] }, { "id": "de-part-encoding", "name": "contentTransferEncoding", "description": "Encoding transformation applied to the part body; defaults to 7bit when absent.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-part-id", "name": "partContentIdentifier", "description": "Identifier of the MIME entity, used for intra-message references such as related parts.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-part-size", "name": "partByteSize", "description": "Size of the decoded part body in octets.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "message-part", "name": "Message content part", "description": "One typed entity in the message content tree, holding either a leaf body or a nested multipart structure.", "media_or_form": [ "MIME entity", "typed payload block", "content event body" ], "serial": true, "identity_strategy": "Content-ID where the channel assigns one; otherwise the message identifier combined with the ordered part path, which is stable only within the message aggregate.", "source_refs": [ "SRC-003", "SRC-019" ] } ], "inline_only_rationale": null }, { "id": "carried-payloads-and-attachments", "name": "Carried payloads: attachments and structured data", "description": "A message carries payloads either by value or by reference. MIME Content-Disposition supplies filename and attachment role; FHIR payload is content as attachment, reference or coded concept; CloudEvents adds datacontenttype and dataschema for machine-interpretable payloads. The message owns the carriage relation and payload digest, not the referenced object's own lifecycle.", "source_refs": [ "SRC-003", "SRC-016", "SRC-018", "SRC-017" ], "questions": [ { "id": "q-pay-mode", "text": "Is each payload carried by value or by reference, and if by reference what resolves the reference and for how long?", "kind": "composition", "answer_data": [ "carriage mode", "reference URI or resource identifier", "resolution authority", "reference validity window" ] }, { "id": "q-pay-schema", "text": "For structured payloads, which schema governs the data and how is schema identity conveyed?", "kind": "interoperability", "answer_data": [ "schema identifier or URI", "schema version", "content type of data", "validation outcome" ] }, { "id": "q-pay-integrity", "text": "What digest or checksum binds the payload to this message, and over what canonical octets was it computed?", "kind": "evidence", "answer_data": [ "digest algorithm", "digest value", "canonicalization applied", "computing agent" ] }, { "id": "q-pay-ownership", "text": "Who owns the carried object and does carriage transfer any rights or obligations?", "kind": "ownership", "answer_data": [ "payload owner reference", "rights statement", "retention obligation on the copy" ] } ], "data_elements": [ { "id": "de-pay-mode", "name": "carriageMode", "description": "Whether the payload is embedded by value or referenced externally.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-003" ] }, { "id": "de-pay-ref", "name": "payloadReference", "description": "Resolvable reference to the carried object when carriage is by reference.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-pay-filename", "name": "presentedFilename", "description": "Filename presented for the payload by the disposition mechanism, which is advisory and untrusted.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-pay-schema", "name": "payloadSchemaIdentifier", "description": "Identifier of the schema the structured payload conforms to.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "de-pay-digest", "name": "payloadDigest", "description": "Cryptographic digest of the payload octets with the algorithm used.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-013" ] } ], "artifacts": [ { "id": "payload-carriage-entry", "name": "Payload carriage entry", "description": "The record binding one carried payload to the message: carriage mode, reference, presented name, declared type, schema and digest.", "media_or_form": [ "attachment entry", "payload element", "data block with schema reference" ], "serial": true, "identity_strategy": "Payload Content-ID or referenced resource identifier where present; otherwise the message identifier plus part path. The carried object's own authoritative identifier is owned by the document/record sibling model.", "source_refs": [ "SRC-003", "SRC-016" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "parties-and-addressing", "name": "Parties and Addressing", "description": "Who released the message, on whose authority, to which endpoints, with what visibility, and by which handling path.", "rationale": "RFC 5321 makes the envelope legally and operationally distinct from the header section; RFC 5322 separates From, Sender and Reply-To; ActivityStreams normatively requires intermediaries to strip bto and bcc; RFC 3464 separates Original-Recipient from Final-Recipient. Addressing therefore carries independent semantics and cannot be folded into content.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-010" ], "layers": [ { "id": "originator-and-authority", "name": "Originator and Sending Authority", "description": "The roles on the sending side and the authority under which the message was released.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-016" ], "findings": [ { "id": "originator-roles-and-authority", "name": "Originator roles, delegation and reply routing", "description": "RFC 5322 distinguishes the author (From), the actual releasing agent (Sender, required when From lists several addresses) and the intended reply target (Reply-To); SMTP separately carries the return path used for failure reports. ActivityStreams distinguishes actor from attributedTo, and FHIR distinguishes sender from subject. Delegated and machine-generated sending is the normal case for agents, so authority must be explicit.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-016" ], "questions": [ { "id": "q-orig-author", "text": "Who authored the message and who actually released it, and are they the same party?", "kind": "authority", "answer_data": [ "author party reference", "releasing agent reference", "delegation basis", "delegation evidence reference" ] }, { "id": "q-orig-onbehalf", "text": "If the message was sent on behalf of another party, what authorises that and is the authorisation still valid at send time?", "kind": "authority", "answer_data": [ "principal party reference", "authorisation instrument reference", "validity window (RFC 3339)", "scope limits" ] }, { "id": "q-orig-reply", "text": "Where should replies and where should failure reports be directed, and why do they differ?", "kind": "relationship", "answer_data": [ "reply target address", "return path address", "divergence reason" ] }, { "id": "q-orig-disclosure", "text": "Is the originator identity fully disclosed as required for the message purpose and jurisdiction?", "kind": "constraint", "answer_data": [ "disclosed identity value", "purpose of the message", "applicable disclosure rule reference", "compliance outcome" ] } ], "data_elements": [ { "id": "de-author", "name": "authorParty", "description": "Party asserted as the author of the message content.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-010" ] }, { "id": "de-releasing-agent", "name": "releasingAgent", "description": "Party or software agent that actually transmitted the message, required when the author is plural or differs from the releaser.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-reply-target", "name": "replyTarget", "description": "Address to which replies should be directed if different from the author address.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-return-path", "name": "returnPath", "description": "Envelope originator to which non-delivery reports are sent; a null value marks the message itself as a report.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Originator roles are reference attributes on the message record pointing at parties governed by the agent/party sibling model; the delegation instrument that authorises sending is itself an artifact of an authority/mandate sibling model, not of the message. Nothing here is separately custodied as a message-owned object." } ] }, { "id": "recipient-addressing", "name": "Recipient Addressing", "description": "The recipient entries on a message, their visibility rules, and how submitted addresses resolve to actual delivery targets.", "source_refs": [ "SRC-001", "SRC-004", "SRC-010", "SRC-017" ], "findings": [ { "id": "recipient-roles-and-visibility", "name": "Recipient roles and addressing visibility", "description": "Primary, secondary and blind recipient roles carry different disclosure obligations. ActivityStreams states that intermediaries MUST remove bto and bcc before redistribution; RFC 5322 treats Bcc handling as sender-agent dependent. A recipient copy therefore legitimately differs from the originator copy, and the model must record which variant it holds.", "source_refs": [ "SRC-001", "SRC-010" ], "questions": [ { "id": "q-rcpt-role", "text": "What addressing role does each recipient entry carry and is that role visible to other recipients?", "kind": "classification", "answer_data": [ "recipient reference", "role code (primary, secondary, blind, audience)", "visibility to other recipients" ] }, { "id": "q-rcpt-variant", "text": "Which addressing variant does this stored copy represent — originator view, recipient view or redistributed view?", "kind": "provenance", "answer_data": [ "copy variant code", "custodian reference", "fields removed or masked" ] }, { "id": "q-rcpt-strip", "text": "Which addressing fields must be removed or masked before this message is forwarded, archived or exported?", "kind": "privacy", "answer_data": [ "field names to remove", "triggering rule reference", "enforcing component" ] }, { "id": "q-rcpt-broadcast", "text": "When the target is a topic, room or audience rather than a named party, how is the addressed set determined and bounded?", "kind": "relationship", "answer_data": [ "topic or room identifier", "audience determination rule", "membership snapshot time (RFC 3339)" ] } ], "data_elements": [ { "id": "de-rcpt-ref", "name": "recipientReference", "description": "Party or endpoint addressed by this entry.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-016" ] }, { "id": "de-rcpt-role", "name": "recipientRole", "description": "Addressing role of the entry: primary, secondary, blind primary, blind secondary or audience.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-001" ] }, { "id": "de-copy-variant", "name": "copyVariant", "description": "Which addressing view this stored copy represents, since blind entries are removed on redistribution.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-target-scope", "name": "targetScope", "description": "Non-party target such as a topic filter, room or channel to which the message was addressed.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-019" ] } ], "artifacts": [ { "id": "recipient-addressing-entry", "name": "Recipient addressing entry", "description": "One recipient slot on a message, holding role, submitted value, resolved value and visibility flags; the unit against which per-recipient delivery evidence is recorded.", "media_or_form": [ "destination field entry", "recipient element", "forward-path entry" ], "serial": true, "identity_strategy": "Message identifier plus recipient ordinal, or the transport's per-recipient correlation value (Original-Recipient) where one exists; the durable endpoint entity is identified by the contact-endpoint sibling model.", "source_refs": [ "SRC-001", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "recipient-resolution", "name": "Recipient resolution, expansion and redirection", "description": "The address a sender submitted is often not the address that received the message. RFC 3464 keeps Original-Recipient for sender correlation and Final-Recipient as seen by the reporting agent, and defines expanded and relayed actions for list expansion and gatewaying. Losing the submitted value breaks correlation, consent scoping and suppression.", "source_refs": [ "SRC-004", "SRC-002", "SRC-012" ], "questions": [ { "id": "q-res-original", "text": "What address did the sender submit for this recipient and what address actually received the message?", "kind": "provenance", "answer_data": [ "submitted address value", "resolved address value", "resolving component", "resolution time (RFC 3339)" ] }, { "id": "q-res-expansion", "text": "Did this recipient entry expand into multiple targets, and is the resulting set knowable to the sender?", "kind": "composition", "answer_data": [ "expansion indicator", "expanded target count", "visibility to sender", "expanding component" ] }, { "id": "q-res-forward", "text": "Was the message redirected or forwarded after acceptance, and does downstream evidence still correlate to the original entry?", "kind": "relationship", "answer_data": [ "redirection indicator", "downstream address", "correlation identifier retained" ] }, { "id": "q-res-permission", "text": "Does a permission or suppression decision taken on the submitted address still hold for the resolved address?", "kind": "constraint", "answer_data": [ "permission scope basis", "re-evaluation requirement", "decision outcome" ] } ], "data_elements": [ { "id": "de-submitted-address", "name": "submittedRecipientAddress", "description": "Recipient address exactly as supplied by the sender, retained for correlation and permission scoping.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-final-address", "name": "resolvedRecipientAddress", "description": "Address at which the handling agent accepted or attempted delivery.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-expansion-flag", "name": "expansionIndicator", "description": "Whether the entry expanded to multiple downstream targets.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-address-type", "name": "addressTypeCode", "description": "Address type qualifier (for example rfc822, x400, jid, topic) needed to interpret the address value.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Resolution outcomes are qualifying attributes of the recipient addressing entry artifact and of delivery status records; they are never custodied or transmitted independently. Creating a separate artifact would duplicate the delivery status notification, which already carries these fields normatively." } ] }, { "id": "envelope-and-handling-path", "name": "Envelope and Handling Path", "description": "The separation between routing instructions and message content, and the recorded path the message actually travelled.", "source_refs": [ "SRC-002", "SRC-001", "SRC-019" ], "findings": [ { "id": "envelope-content-separation", "name": "Envelope versus content separation", "description": "RFC 5321 states the delivery reverse-path is simply the address given in MAIL FROM, independent of any header field, and that content is what is sent in DATA. Header From and envelope originator routinely differ, which is the basis of both legitimate forwarding and impersonation. Any model that stores only one of the two loses the ability to reason about authenticity and bounce routing.", "source_refs": [ "SRC-002", "SRC-001", "SRC-006" ], "questions": [ { "id": "q-env-pair", "text": "What are the envelope originator and envelope recipients, and how do they differ from the header-declared parties?", "kind": "identity", "answer_data": [ "envelope originator value", "envelope recipient values", "header originator value", "alignment outcome" ] }, { "id": "q-env-auth", "text": "Which of the two identifier sets was authenticated, and by which mechanism?", "kind": "evidence", "answer_data": [ "authenticated identifier", "mechanism (spf, dkim, dmarc, auth)", "result value", "evaluating authority" ] }, { "id": "q-env-retain", "text": "Is envelope data retained after delivery, and under what rule may it be erased?", "kind": "retention", "answer_data": [ "retention indicator", "retention basis", "erasure rule reference" ] }, { "id": "q-env-nonemail", "text": "For non-mail channels, which construct plays the envelope role and what is its retention behaviour?", "kind": "interoperability", "answer_data": [ "channel identifier", "envelope-equivalent construct", "broker or server retention behaviour" ] } ], "data_elements": [ { "id": "de-env-originator", "name": "envelopeOriginator", "description": "Transport-level originator used for routing and failure reporting; may be null on report messages.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-env-recipients", "name": "envelopeRecipients", "description": "Transport-level recipient set actually used for routing, which may differ from declared destination fields.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-env-equiv", "name": "envelopeEquivalentConstruct", "description": "Channel-specific construct fulfilling the envelope role (SMTP paths, XMPP to/from, MQTT topic, Matrix room).", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-017", "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "Envelope values are transient routing state that standards deliberately do not persist in the message content; where they are preserved they appear inside the handling trace record or the delivery status notification, both of which are modelled as artifacts. Minting a separate envelope artifact would assert a persistence that RFC 5321 does not require and that ePrivacy traffic-data rules actively discourage." }, { "id": "handling-trace", "name": "Handling trace and custody path", "description": "Each relay must prepend its own trace entry and must not alter existing ones, producing an append-only, reverse-chronological custody path; Matrix achieves the equivalent through a signed event graph with prev_events. The trace is the primary provenance evidence for when and where a message was handled, and is the main source of traffic data subject to erasure duties.", "source_refs": [ "SRC-002", "SRC-019", "SRC-014" ], "questions": [ { "id": "q-trace-order", "text": "What is the ordered sequence of handling agents and what did each one assert about time and origin?", "kind": "provenance", "answer_data": [ "handling agent identifier", "received-from value", "asserted timestamp (RFC 3339)", "sequence position" ] }, { "id": "q-trace-integrity", "text": "What guarantees that trace entries were not altered or reordered after the fact?", "kind": "quality", "answer_data": [ "append-only guarantee", "signature or hash chain reference", "verification outcome" ] }, { "id": "q-trace-trust", "text": "Which trace entries were created inside the trust boundary of the recording organisation and which are untrusted assertions?", "kind": "security", "answer_data": [ "trust boundary identifier", "entry classification", "policy applied to untrusted entries" ] }, { "id": "q-trace-erase", "text": "When must trace and traffic data be erased or anonymised, and what is the lawful basis for retaining it longer?", "kind": "retention", "answer_data": [ "erasure trigger", "retention basis", "permitted purpose", "approving role" ] } ], "data_elements": [ { "id": "de-trace-agent", "name": "handlingAgentIdentifier", "description": "Identifier of the agent that handled the message at this hop.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-trace-time", "name": "handlingTimestamp", "description": "Time asserted by the handling agent for this hop, recorded with explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-007" ] }, { "id": "de-trace-position", "name": "tracePosition", "description": "Position of the entry in the handling sequence; trace entries are prepended, so order is significant.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-trace-trusted", "name": "withinTrustBoundary", "description": "Whether the entry was created inside the recording organisation's administrative management domain.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "handling-trace-record", "name": "Handling trace record", "description": "Append-only sequence of custody entries describing each agent that received, relayed or gatewayed the message, with asserted times and trust classification.", "media_or_form": [ "trace field block", "signed event graph edges", "broker handling log" ], "serial": true, "identity_strategy": "Message identifier plus trace position; where the channel signs each hop, the hop signature or event identifier is authoritative. Trace entries are never identified by timestamp alone because clocks across hops are unsynchronised and assertions may be forged.", "source_refs": [ "SRC-002", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "conversation-structure", "name": "Conversation Structure", "description": "How messages relate to one another: threads, reply chains, derived messages and request-response correlation.", "rationale": "RFC 5322 defines In-Reply-To and References; XMPP defines a thread element with a parent attribute; Matrix defines m.relates_to reply and thread relations; FHIR defines inResponseTo, basedOn and partOf. Conversation structure is expressed by independent, sometimes conflicting mechanisms and needs its own bundle.", "source_refs": [ "SRC-001", "SRC-008", "SRC-016", "SRC-019" ], "layers": [ { "id": "threading-and-continuity", "name": "Threading and Continuity", "description": "Grouping messages into conversations and reconstructing reply order from per-message pointers.", "source_refs": [ "SRC-001", "SRC-008", "SRC-019" ], "findings": [ { "id": "thread-identity-and-membership", "name": "Thread identity, membership and participation scope", "description": "Threads are constructed differently per channel: XMPP carries an opaque thread identifier with an optional parent, Matrix uses a room plus a thread relation to a root event, and mail has no thread field at all and must be reconstructed from References. Thread identity is therefore either channel-assigned or derived, and the model must record which.", "source_refs": [ "SRC-008", "SRC-019", "SRC-001" ], "questions": [ { "id": "q-thr-source", "text": "Is the thread identifier channel-assigned or derived by reconstruction, and by which algorithm?", "kind": "identity", "answer_data": [ "thread identifier", "assignment mode", "reconstruction algorithm reference", "confidence" ] }, { "id": "q-thr-membership", "text": "What determines whether a message belongs to the thread, and can membership change after the fact?", "kind": "composition", "answer_data": [ "membership rule", "mutability indicator", "reassignment event reference" ] }, { "id": "q-thr-participants", "text": "Who participates in the thread, and does a participant see the whole thread or only the messages addressed to them?", "kind": "access", "answer_data": [ "participant reference", "join and leave times (RFC 3339)", "visible message range" ] }, { "id": "q-thr-split", "text": "How are thread splits, merges and subthreads represented without breaking existing references?", "kind": "relationship", "answer_data": [ "parent thread identifier", "split or merge event", "affected message identifiers" ] } ], "data_elements": [ { "id": "de-thread-id", "name": "threadIdentifier", "description": "Identifier of the conversation grouping to which the message belongs.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-019" ] }, { "id": "de-thread-mode", "name": "threadAssignmentMode", "description": "Whether thread membership was asserted by the channel or derived by reconstruction.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "de-thread-parent", "name": "parentThreadIdentifier", "description": "Identifier of a parent conversation when the thread branches from an earlier one.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-thread-root", "name": "threadRootMessage", "description": "Message that roots the thread, where the channel defines threads by reference to a root.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [ { "id": "conversation-thread", "name": "Conversation thread", "description": "The grouping object for messages exchanged in one conversation, holding thread identity, root, participation window and split/merge history.", "media_or_form": [ "thread grouping record", "room or channel conversation view" ], "serial": false, "identity_strategy": "Channel-assigned thread or room identifier where one exists; otherwise a UUID or ULID assigned by the adopting Dimension together with the reconstruction algorithm reference, so that derived threads are never mistaken for asserted ones.", "source_refs": [ "SRC-008", "SRC-019" ] } ], "inline_only_rationale": null }, { "id": "reply-and-reference-chains", "name": "Reply and reference chains", "description": "Mail carries In-Reply-To for the immediate parent and References for the ancestor chain; ActivityStreams carries inReplyTo; Matrix carries an explicit reply relation. These pointers can be missing, wrong, or point at messages the holder cannot resolve, so chain reconstruction must be treated as fallible evidence rather than fact.", "source_refs": [ "SRC-001", "SRC-010", "SRC-019" ], "questions": [ { "id": "q-rep-parent", "text": "Which message does this one reply to, and is that parent resolvable in the current holding?", "kind": "relationship", "answer_data": [ "parent message identifier", "resolution status", "holding location" ] }, { "id": "q-rep-chain", "text": "What ancestor chain is asserted, and does it agree with the parent pointer and the thread assignment?", "kind": "validation", "answer_data": [ "ancestor identifier list", "consistency outcome", "conflict description" ] }, { "id": "q-rep-broken", "text": "How is a broken, forged or circular reference chain detected and represented?", "kind": "quality", "answer_data": [ "defect type", "detection rule", "representation of the unresolved link" ] }, { "id": "q-rep-quote", "text": "Does the reply quote or transclude the parent content, and does that create a second copy under separate custody?", "kind": "provenance", "answer_data": [ "quotation indicator", "quoted extent", "custody implication" ] } ], "data_elements": [ { "id": "de-in-reply-to", "name": "inReplyToMessage", "description": "Identifier of the immediate message being replied to.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] }, { "id": "de-references", "name": "referenceChain", "description": "Ordered ancestor identifiers asserted by the sender for conversation reconstruction.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-ref-status", "name": "referenceResolutionStatus", "description": "Whether each asserted reference resolves within the current holding.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "Reply pointers are attributes of the message record itself and are transmitted only as part of it; the reconstructed conversation graph is a derived projection over those attributes, materialised through the conversation thread artifact rather than as an independent object." } ] }, { "id": "relations-and-correlation", "name": "Derived Messages and Correlation", "description": "Messages produced from other messages, and the correlation of a response to its request.", "source_refs": [ "SRC-001", "SRC-016", "SRC-017" ], "findings": [ { "id": "derived-and-redistributed-messages", "name": "Forwarded, resent and corrected messages", "description": "RFC 5322 resent fields explicitly reintroduce a message to new recipients without making it a new message, and require their own resent identifier and date; Matrix supports replacement and redaction relations. Redistribution changes the accountable sender and the addressing view while preserving the original content, so the derivation relation must be typed.", "source_refs": [ "SRC-001", "SRC-019", "SRC-010" ], "questions": [ { "id": "q-der-type", "text": "What kind of derivation produced this message: forward, resend, correction, replacement or recall?", "kind": "classification", "answer_data": [ "derivation type code", "source message identifier", "deriving party reference", "derivation time (RFC 3339)" ] }, { "id": "q-der-accountability", "text": "Who is accountable for the redistributed message, and does original authorship survive the derivation?", "kind": "ownership", "answer_data": [ "redistributing party", "original author reference", "attribution statement" ] }, { "id": "q-der-fidelity", "text": "Was the original content preserved unaltered, and how is any alteration recorded?", "kind": "quality", "answer_data": [ "fidelity indicator", "alteration description", "integrity evidence reference" ] }, { "id": "q-der-recall", "text": "Does the channel support withdrawal of an already-released message, and what does withdrawal actually guarantee?", "kind": "exception", "answer_data": [ "withdrawal support indicator", "withdrawal scope", "copies not reachable by withdrawal" ] } ], "data_elements": [ { "id": "de-derivation-type", "name": "derivationType", "description": "Typed relation to a predecessor message: forward, resend, correction, replacement or withdrawal.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-019" ] }, { "id": "de-source-message", "name": "sourceMessage", "description": "Identifier of the message from which this one derives.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-resent-id", "name": "redistributionIdentifier", "description": "Distinct identifier assigned to the act of redistribution, separate from the original message identifier.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-resent-time", "name": "redistributionTime", "description": "Time the redistribution act occurred, with explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "A derived message is itself an instance of the message record artifact; what is new here is only the typed relation and the redistribution identifier carried on that record. Introducing a separate derivation artifact would create a second identity for the same communication act." }, { "id": "request-response-correlation", "name": "Request-response correlation and expected reply", "description": "Machine messaging makes the reply contract explicit: MQTT carries Correlation Data and a Response Topic, XMPP correlates by stanza id, and FHIR distinguishes basedOn (the order being fulfilled) from inResponseTo. For agent-to-agent communication this is the difference between a conversational reply and a contractual response to a request.", "source_refs": [ "SRC-017", "SRC-008", "SRC-016" ], "questions": [ { "id": "q-corr-token", "text": "What correlation token binds this response to its request, and who minted it?", "kind": "identity", "answer_data": [ "correlation token", "minting party", "token scope and lifetime" ] }, { "id": "q-corr-target", "text": "Where should the response be sent, and is that target different from the request's reply address?", "kind": "process", "answer_data": [ "response target address or topic", "divergence from reply target", "validity window" ] }, { "id": "q-corr-expect", "text": "Is a response required, optional or forbidden, and what happens if none arrives within the expected window?", "kind": "constraint", "answer_data": [ "response obligation code", "expected response deadline (RFC 3339)", "timeout handling rule" ] }, { "id": "q-corr-fulfil", "text": "Does this message fulfil a prior request or order, and is that fulfilment complete or partial?", "kind": "state", "answer_data": [ "fulfilled request reference", "fulfilment completeness", "remaining obligation" ] } ], "data_elements": [ { "id": "de-correlation-token", "name": "correlationToken", "description": "Opaque value binding a response to the request that elicited it.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-008" ] }, { "id": "de-response-target", "name": "responseTarget", "description": "Address, topic or endpoint at which the response is expected.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-response-obligation", "name": "responseObligation", "description": "Whether a response is required, optional or not expected.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-based-on", "name": "fulfilsRequest", "description": "Reference to the request, order or plan this message fulfils, distinct from a conversational reply pointer.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Correlation values live only on the request and response message records and have no independent custody, transmission or retention. The request itself is a message record; representing the correlation as its own artifact would duplicate that record without adding a governable object." } ] } ] }, { "id": "transit-and-evidence", "name": "Transit and Evidence", "description": "The state of the message in transit, its time points, and the evidence produced about delivery and recipient disposition.", "rationale": "RFC 3464 and RFC 8098 define two structurally different evidence records with different issuers and different reliability; eIDAS attaches legal presumptions only to registered delivery evidence; MQTT defines delivery guarantees at the protocol level. Evidence is therefore a bundle in its own right and must not be reduced to a status field.", "source_refs": [ "SRC-004", "SRC-005", "SRC-013", "SRC-017" ], "layers": [ { "id": "transmission-state", "name": "Transmission State and Time", "description": "The lifecycle state of a message and the distinct time points that mark its progress.", "source_refs": [ "SRC-016", "SRC-004", "SRC-007" ], "findings": [ { "id": "message-state-model", "name": "Message state model and terminal outcomes", "description": "FHIR types Communication.status from an event status value set including in-progress, completed, not-done, entered-in-error and unknown; DSN types the transport action as failed, delayed, delivered, relayed or expanded. These are different state machines — one about the communication act, one about a delivery attempt for one recipient — and both are needed.", "source_refs": [ "SRC-016", "SRC-004", "SRC-012" ], "questions": [ { "id": "q-st-levels", "text": "At which level is state asserted — the whole message, one recipient entry, or one delivery attempt?", "kind": "state", "answer_data": [ "state scope code", "subject reference", "asserting agent" ] }, { "id": "q-st-terminal", "text": "Which states are terminal, which are retryable, and what distinguishes a permanent from a transient failure?", "kind": "lifecycle", "answer_data": [ "state value", "terminality flag", "failure class (permanent, transient)", "retry window (RFC 3339)" ] }, { "id": "q-st-transitions", "text": "Which state transitions are permitted and which agent role may assert each transition?", "kind": "authority", "answer_data": [ "from state", "to state", "authorised role", "required evidence" ] }, { "id": "q-st-erroneous", "text": "How is a message recorded as entered in error or never actually sent, without deleting the record?", "kind": "exception", "answer_data": [ "error state value", "reason code", "correcting party", "correction time (RFC 3339)" ] } ], "data_elements": [ { "id": "de-msg-status", "name": "messageStatus", "description": "Lifecycle state of the communication act as a whole.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "de-rcpt-action", "name": "recipientDeliveryAction", "description": "Outcome of the delivery attempt for one recipient: failed, delayed, delivered, relayed or expanded.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-status-reason", "name": "statusReason", "description": "Coded or textual reason accompanying a non-routine state.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-012" ] }, { "id": "de-failure-class", "name": "failureClass", "description": "Whether a failure is permanent, persistent transient or a success confirmation, from the enhanced status class.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "State values are attributes carried on the message record and on delivery status notification artifacts; the notifications themselves are the custodied objects. Modelling state as an artifact would either duplicate the delivery status notification or invent a record that no cited standard transmits." }, { "id": "message-time-points", "name": "Distinct time points and clock trust", "description": "Standards deliberately keep several times apart: the origination date is when the creator finished the message for transmission, not when transport occurred; DSN adds Arrival-Date, Last-Attempt-Date and Will-Retry-Until; FHIR separates sent from received; Matrix records origin_server_ts. RFC 3339 requires an explicit offset and reserves -00:00 for unknown local offset.", "source_refs": [ "SRC-001", "SRC-004", "SRC-016", "SRC-007", "SRC-019" ], "questions": [ { "id": "q-t-points", "text": "Which distinct time points are recorded for this message and what does each one actually mean?", "kind": "temporal", "answer_data": [ "time point name", "value with explicit offset", "asserting agent", "semantic definition reference" ] }, { "id": "q-t-observation", "text": "Is event time separated from observation or ingestion time, and which one is authoritative for ordering?", "kind": "temporal", "answer_data": [ "event time", "observation time", "ordering basis", "tie-break rule" ] }, { "id": "q-t-clock", "text": "Whose clock produced each timestamp and what is known about its trustworthiness or synchronisation?", "kind": "quality", "answer_data": [ "clock owner", "synchronisation source", "trust classification", "known skew" ] }, { "id": "q-t-offset", "text": "Is the sender's local offset known, and how is an unknown offset represented rather than guessed?", "kind": "temporal", "answer_data": [ "offset value", "unknown-offset representation", "originating locale if known" ] }, { "id": "q-t-expiry", "text": "Does the message expire, and what happens to it and to its evidence at expiry?", "kind": "lifecycle", "answer_data": [ "expiry instant or interval", "expiry behaviour", "evidence generated at expiry" ] } ], "data_elements": [ { "id": "de-origination-time", "name": "originationTime", "description": "Time the creator completed the message for transmission, with explicit offset per RFC 3339.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "de-sent-time", "name": "submissionTime", "description": "Time the message was released into the channel by the sending agent.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-019" ] }, { "id": "de-received-time", "name": "receiptTime", "description": "Time a handling agent or recipient endpoint accepted the message.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-004" ] }, { "id": "de-observation-time", "name": "observationTime", "description": "Time the recording system observed or ingested the fact, kept separate from the event time it describes.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-018" ] }, { "id": "de-expiry", "name": "expiryInterval", "description": "Interval or instant after which the message must not be delivered and may be discarded.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "Time points are qualifying attributes of the message record, the handling trace record and the evidence artifacts already defined; no cited standard transmits or custodies them as a standalone object, and doing so would fragment the very correlation these fields exist to support." } ] }, { "id": "delivery-evidence", "name": "Delivery Evidence", "description": "Records produced by transport and delivery services about what happened to the message, and the guarantees they do and do not confer.", "source_refs": [ "SRC-004", "SRC-013", "SRC-017", "SRC-021" ], "findings": [ { "id": "delivery-status-records", "name": "Delivery status records and outcome coding", "description": "A DSN is a distinct message reporting per-message fields (reporting agent, arrival date, envelope identifier) and per-recipient fields (final recipient, action, status code, diagnostic code, retry window). The enhanced status code is a three-part class/subject/detail structure maintained in an IANA registry, which is the correct vocabulary source rather than local status strings.", "source_refs": [ "SRC-004", "SRC-012", "SRC-002" ], "questions": [ { "id": "q-ds-issuer", "text": "Which agent issued the status record and was it authorised to speak for the delivery attempt?", "kind": "authority", "answer_data": [ "reporting agent identifier", "authority basis", "trust boundary position" ] }, { "id": "q-ds-code", "text": "What outcome code was reported, from which registry, and how does it map to the model's outcome classifier?", "kind": "interoperability", "answer_data": [ "status code value", "code registry reference", "mapped outcome class", "mapping confidence" ] }, { "id": "q-ds-correlate", "text": "How does the status record correlate back to the original message and to a specific recipient entry?", "kind": "relationship", "answer_data": [ "original message identifier", "envelope identifier", "original recipient value", "correlation confidence" ] }, { "id": "q-ds-multi", "text": "Can multiple, later or contradictory status records exist for the same recipient, and which one prevails?", "kind": "validation", "answer_data": [ "record sequence", "supersession rule", "conflict resolution outcome" ] } ], "data_elements": [ { "id": "de-ds-reporter", "name": "reportingAgent", "description": "Agent that attempted delivery and issued the status record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-ds-status", "name": "enhancedStatusCode", "description": "Three-part class/subject/detail outcome code from the governed registry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "de-ds-diagnostic", "name": "diagnosticDetail", "description": "Channel-specific diagnostic text accompanying the outcome code.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-ds-retry", "name": "retryWindowEnd", "description": "Time until which further delivery attempts will be made for a delayed outcome.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-007" ] } ], "artifacts": [ { "id": "delivery-status-record", "name": "Delivery status record", "description": "A machine-readable report about the outcome of a delivery attempt for one or more recipients, issued by a handling agent and correlatable to the original submission.", "media_or_form": [ "delivery status notification", "broker acknowledgement record", "transport report message" ], "serial": true, "identity_strategy": "The report's own message identifier where it is transmitted as a message; otherwise the original envelope identifier plus final recipient plus reporting agent. Reports are ordered by issue time but never identified by it.", "source_refs": [ "SRC-004", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "registered-delivery-evidence", "name": "Registered delivery evidence and legal presumption", "description": "An electronic registered delivery service transmits data and provides evidence about its handling, including proof of sending and receiving. Under eIDAS the presumptions of integrity, sending, receipt and accuracy of date and time attach only to qualified services; ETSI EN 319 522 names the evidence set (submission, relay, notification, consignment acceptance or rejection, retrieval, expiration). Evidence must not be conflated with ordinary status reports.", "source_refs": [ "SRC-013", "SRC-021", "SRC-004" ], "questions": [ { "id": "q-re-type", "text": "Which named evidence event does this record attest, and at which point of the transfer?", "kind": "evidence", "answer_data": [ "evidence type code", "transfer point", "subject message identifier", "event time (RFC 3339)" ] }, { "id": "q-re-issuer", "text": "Who issued the evidence, under which issuing policy, and is that issuer a qualified provider?", "kind": "authority", "answer_data": [ "issuer identifier", "issuing policy reference", "qualified status", "supervisory listing reference" ] }, { "id": "q-re-presumption", "text": "What legal presumption, if any, does this evidence carry and in which jurisdiction?", "kind": "constraint", "answer_data": [ "presumption claimed", "jurisdiction", "legal basis reference", "rebuttability note" ] }, { "id": "q-re-binding", "text": "How is the evidence cryptographically bound to the exact payload it attests?", "kind": "evidence", "answer_data": [ "payload digest", "digest algorithm", "signature or seal reference", "validation outcome" ] }, { "id": "q-re-preserve", "text": "How long must the evidence remain verifiable, and what preserves its validity beyond signature expiry?", "kind": "retention", "answer_data": [ "evidence retention period", "preservation mechanism", "re-validation schedule" ] } ], "data_elements": [ { "id": "de-re-type", "name": "evidenceEventType", "description": "Named evidence event attested, from the registered delivery evidence set.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-013" ] }, { "id": "de-re-issuer", "name": "evidenceIssuer", "description": "Delivery service provider that issued the evidence.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-013" ] }, { "id": "de-re-qualified", "name": "qualifiedStatusAsserted", "description": "Whether the issuer is asserted to be a qualified provider, and the listing that supports the assertion.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-re-time", "name": "evidenceEventTime", "description": "Time of the attested event as sealed by the issuer, with explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-007" ] } ], "artifacts": [ { "id": "registered-delivery-evidence-token", "name": "Registered delivery evidence token", "description": "A signed or sealed record issued by a registered delivery service attesting a named event in the transfer, bound to the payload digest and the identified sender and recipient.", "media_or_form": [ "structured evidence document", "sealed evidence token", "rendered evidence report" ], "serial": true, "identity_strategy": "Evidence identifier assigned by the issuing service, which is the authoritative master system for this object; the subject message identifier and payload digest provide correlation but never identity.", "source_refs": [ "SRC-021", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "delivery-guarantee-and-duplicates", "name": "Delivery guarantee level and duplicate control", "description": "MQTT makes the guarantee explicit and bounded: at most once may lose messages, at least once may duplicate, exactly once is assured by a four-step handshake. CloudEvents pushes deduplication onto consumers via source+id uniqueness. An agent must know the guarantee before treating an absent acknowledgement as non-delivery or a repeat as a new message.", "source_refs": [ "SRC-017", "SRC-018", "SRC-004" ], "questions": [ { "id": "q-dg-level", "text": "What delivery guarantee did the channel provide for this message, and who selected it?", "kind": "constraint", "answer_data": [ "guarantee level code", "selecting party", "channel identifier" ] }, { "id": "q-dg-dup", "text": "How is a duplicate delivery detected and what is the idempotency key?", "kind": "validation", "answer_data": [ "idempotency key components", "duplicate detection rule", "action on duplicate" ] }, { "id": "q-dg-absent", "text": "What may be concluded from the absence of an acknowledgement under this guarantee level?", "kind": "decision", "answer_data": [ "inference permitted", "inference forbidden", "escalation rule", "observation window" ] }, { "id": "q-dg-retained", "text": "Does the channel retain the message for later subscribers or offline recipients, and for how long?", "kind": "retention", "answer_data": [ "retention behaviour", "retention period", "recipients affected" ] } ], "data_elements": [ { "id": "de-dg-level", "name": "deliveryGuaranteeLevel", "description": "Asserted guarantee: at most once, at least once or exactly once.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-dg-key", "name": "idempotencyKey", "description": "Key used to recognise redelivery of the same message rather than a new one.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "de-dg-attempt", "name": "deliveryAttemptCount", "description": "Number of delivery attempts recorded for a recipient entry.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-dg-retained", "name": "channelRetentionBehaviour", "description": "Whether the channel holds the message for later or offline delivery, and for how long.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "Guarantee level and idempotency key are protocol-level qualifiers recorded on the message record and on delivery status records; the acknowledgement packets that implement them are transient protocol units that no cited standard requires to be preserved as separate governed objects." } ] }, { "id": "recipient-disposition", "name": "Recipient Disposition", "description": "What the recipient did with the message, and the strict limits on what such reports prove.", "source_refs": [ "SRC-005", "SRC-019", "SRC-016" ], "findings": [ { "id": "disposition-and-read-evidence", "name": "Disposition notifications and read evidence", "description": "MDN reports a disposition (displayed, deleted, dispatched, processed) together with an action mode (manual or automatic) and a sending mode; Matrix reports read receipts and read markers. RFC 8098 states plainly that MDNs do not provide non-repudiation with proof of delivery, can be forged as easily as ordinary mail, may be lost, and may be bypassed by the recipient, and it requires recipient consent before sending.", "source_refs": [ "SRC-005", "SRC-019", "SRC-014" ], "questions": [ { "id": "q-di-type", "text": "What disposition is reported, and does it mean the content was actually presented to a person?", "kind": "evidence", "answer_data": [ "disposition type", "action mode (manual, automatic)", "sending mode", "presentation inference permitted" ] }, { "id": "q-di-request", "text": "Did the sender request a disposition notification, and did the recipient consent to sending one?", "kind": "authority", "answer_data": [ "notification requested indicator", "request target address", "recipient consent indicator", "consent capture time (RFC 3339)" ] }, { "id": "q-di-reliability", "text": "What is the evidential weight of this report and which specific claims may not be made from it?", "kind": "quality", "answer_data": [ "forgeability note", "non-repudiation claim permitted", "absence-of-report interpretation" ] }, { "id": "q-di-privacy", "text": "What does a disposition report disclose about the recipient, and is that disclosure permissible?", "kind": "privacy", "answer_data": [ "disclosed attributes", "lawful basis", "suppression option offered" ] }, { "id": "q-di-abuse", "text": "How is the notification target validated to prevent amplification or mail-bombing abuse?", "kind": "security", "answer_data": [ "target validation rule", "mismatch with return path", "action on mismatch" ] } ], "data_elements": [ { "id": "de-di-type", "name": "dispositionType", "description": "Reported handling of the message by the recipient: displayed, deleted, dispatched or processed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-di-mode", "name": "dispositionMode", "description": "Whether the action and the notification were manual or automatic.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-di-original", "name": "originalMessageIdentifier", "description": "Identifier of the message the disposition report refers to.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-di-weight", "name": "evidentialWeight", "description": "Recorded classification of how far the report may be relied on, given known forgeability.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "disposition-notification-record", "name": "Disposition notification record", "description": "A recipient-side report of what was done with a message, carrying disposition type, mode, correlation identifiers and an explicit reliability qualification.", "media_or_form": [ "message disposition notification", "read receipt event", "acknowledgement record" ], "serial": true, "identity_strategy": "The report's own message or event identifier assigned by the reporting system; correlation uses the original message identifier and original recipient, which are not identity because a single message may yield several conflicting reports.", "source_refs": [ "SRC-005", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "trust-and-protection", "name": "Trust and Protection", "description": "Whether the message really came from whom it claims, and whether its content was kept confidential and unaltered.", "rationale": "RFC 8601 defines a normative way to record authentication outcomes and a strict trust-boundary rule; MIME, Matrix and eIDAS all bind integrity to specific octets under specific canonicalisation. Authenticity and confidentiality are independent of delivery outcome and require a separate bundle.", "source_refs": [ "SRC-006", "SRC-019", "SRC-013", "SRC-003" ], "layers": [ { "id": "origin-authentication", "name": "Origin Authentication", "description": "Recorded outcomes of mechanisms that test whether the asserted origin is genuine.", "source_refs": [ "SRC-006", "SRC-009", "SRC-002" ], "findings": [ { "id": "origin-authentication-assertions", "name": "Origin authentication results and trust boundaries", "description": "Authentication-Results records, per method, which identifier was tested and with what result, stamped by an authentication service identifier. The specification requires handling agents to delete any instance claiming to originate inside their trust boundary when it arrives from outside, and warns that consumers should not interpret the field unless configured to trust the stamper.", "source_refs": [ "SRC-006", "SRC-002" ], "questions": [ { "id": "q-oa-method", "text": "Which authentication methods were evaluated, against which identifier, with what result?", "kind": "evidence", "answer_data": [ "method name", "evaluated identifier", "result value", "evaluation time (RFC 3339)" ] }, { "id": "q-oa-authority", "text": "Which authentication service stamped the result and is it inside the consuming organisation's trust boundary?", "kind": "authority", "answer_data": [ "authentication service identifier", "trust boundary relation", "trust decision" ] }, { "id": "q-oa-forged", "text": "How are forged or externally injected authentication assertions detected and removed?", "kind": "security", "answer_data": [ "detection rule", "removal action", "audit entry reference" ] }, { "id": "q-oa-consume", "text": "What downstream decision may be based on the result, and what must not be inferred from a pass?", "kind": "decision", "answer_data": [ "permitted decisions", "prohibited inferences", "fallback when result is none or temperror" ] } ], "data_elements": [ { "id": "de-oa-service", "name": "authenticationServiceIdentifier", "description": "Token identifying the service that performed the authentication checks.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-oa-method", "name": "authenticationMethod", "description": "Mechanism evaluated, such as domain signature, path authorisation, alignment policy or reverse lookup.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-oa-result", "name": "authenticationResult", "description": "Outcome value from the governed result vocabulary.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-oa-identifier", "name": "authenticatedIdentifier", "description": "The specific identifier that the method actually authenticated, which may not be the visible author address.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-002" ] } ], "artifacts": [ { "id": "authentication-results-assertion", "name": "Authentication results assertion", "description": "A stamped record of authentication outcomes for one message, attributable to a named authentication service and scoped to a trust boundary.", "media_or_form": [ "authentication results header field", "verification report record" ], "serial": true, "identity_strategy": "Message identifier plus authentication service identifier plus evaluation time, because a message legitimately carries several assertions from different services; the assertion has no independent master identifier.", "source_refs": [ "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "confidentiality-and-integrity", "name": "Confidentiality and Integrity", "description": "What protection was applied to which parts of the message, and what integrity can be demonstrated afterwards.", "source_refs": [ "SRC-003", "SRC-019", "SRC-013", "SRC-014" ], "findings": [ { "id": "content-protection-and-integrity", "name": "Protection scope, integrity and post-hoc verifiability", "description": "Protection is scoped: MIME allows signing or encrypting individual entities, Matrix encrypts room events end to end while leaving structural fields visible, and eIDAS requires protection of transmitted data against unauthorised alteration. What is protected, what remains observable, and whether verification is still possible after storage transformations are separate questions.", "source_refs": [ "SRC-003", "SRC-019", "SRC-013", "SRC-014" ], "questions": [ { "id": "q-cp-scope", "text": "Which parts of the message are confidentiality-protected and which metadata remains observable to intermediaries?", "kind": "security", "answer_data": [ "protected part references", "observable metadata list", "protection mechanism" ] }, { "id": "q-cp-verify", "text": "Can integrity still be verified from the stored form, and what canonicalisation is required to do so?", "kind": "validation", "answer_data": [ "canonicalisation rule", "verification procedure", "last successful verification time (RFC 3339)", "verification outcome" ] }, { "id": "q-cp-transform", "text": "Which storage or transport transformations would invalidate the integrity evidence, and are they prohibited?", "kind": "constraint", "answer_data": [ "prohibited transformations", "permitted transformations", "mitigation when transformation is unavoidable" ] }, { "id": "q-cp-recovery", "text": "If content is end-to-end protected, what remains discoverable, auditable or retainable by the custodian?", "kind": "access", "answer_data": [ "custodian-visible fields", "recoverability of plaintext", "governance consequence for retention and disclosure" ] } ], "data_elements": [ { "id": "de-cp-mechanism", "name": "protectionMechanism", "description": "Mechanism applied to protect confidentiality or integrity of message content.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-019" ] }, { "id": "de-cp-scope", "name": "protectionScope", "description": "Which parts or fields the protection covers, and which remain in clear.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-003" ] }, { "id": "de-cp-canon", "name": "canonicalisationRule", "description": "Rule under which the protected octets were canonicalised, required for later verification.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-003" ] }, { "id": "de-cp-verified", "name": "lastVerificationOutcome", "description": "Outcome and time of the most recent integrity verification of the stored form.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-007" ] } ], "artifacts": [ { "id": "protected-content-object", "name": "Protected content object", "description": "The signed or encrypted representation of message content together with the parameters needed to verify or decrypt it later, excluding key material itself.", "media_or_form": [ "signed MIME entity", "encrypted event content", "sealed payload" ], "serial": true, "identity_strategy": "Message identifier plus protected part path; where the protection mechanism assigns its own object or signature identifier, that identifier is authoritative. Keys and trust anchors are identified by a key-management sibling model.", "source_refs": [ "SRC-003", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "custody-and-governance", "name": "Custody and Governance", "description": "The permission under which contact was made, the opt-out signals the message carries, and how retained copies are kept, disposed of and disclosed.", "rationale": "ePrivacy Article 13 conditions unsolicited electronic contact on prior consent and a valid opt-out address; GDPR imposes storage limitation, demonstrable consent and a right to object; NARA schedules electronic messages as records; RFC 8058 makes opt-out a message-carried mechanism. Governance is therefore intrinsic to the message, not an afterthought.", "source_refs": [ "SRC-014", "SRC-015", "SRC-020", "SRC-009" ], "layers": [ { "id": "permission-and-suppression", "name": "Permission and Suppression", "description": "The basis relied on to contact a recipient and the opt-out mechanics carried by the message.", "source_refs": [ "SRC-014", "SRC-015", "SRC-009", "SRC-008" ], "findings": [ { "id": "contact-permission-basis", "name": "Permission basis asserted at send time", "description": "Direct-marketing electronic mail generally requires prior consent, with a narrow soft opt-in for existing customers of similar products who were given an easy objection route; GDPR requires the controller to be able to demonstrate consent and makes withdrawal as easy as giving. The message model records the basis cited and the evidence pointer at send time; the consent record itself is governed by a sibling model.", "source_refs": [ "SRC-014", "SRC-015", "SRC-008" ], "questions": [ { "id": "q-pb-basis", "text": "On what basis was this recipient contacted for this purpose on this channel?", "kind": "authority", "answer_data": [ "basis code (consent, soft opt-in, contract, legal obligation, legitimate interest)", "purpose", "channel", "evidence reference" ] }, { "id": "q-pb-asof", "text": "When was the permission state evaluated relative to release, and was a fresher state available?", "kind": "temporal", "answer_data": [ "evaluation time (RFC 3339)", "release time", "staleness window", "re-evaluation requirement" ] }, { "id": "q-pb-scope", "text": "Does the basis cover this purpose and this resolved address, or only the address originally submitted?", "kind": "constraint", "answer_data": [ "covered purposes", "covered endpoints", "gap description", "decision outcome" ] }, { "id": "q-pb-demonstrate", "text": "What would be produced to demonstrate the permission if challenged, and where is it held?", "kind": "evidence", "answer_data": [ "evidence artifact reference", "holding system", "retention period", "retrieval procedure" ] } ], "data_elements": [ { "id": "de-pb-basis", "name": "permissionBasisCode", "description": "Legal or policy basis relied on to contact the recipient for the message's purpose.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "de-pb-evidence", "name": "permissionEvidenceReference", "description": "Pointer to the externally governed consent or permission record relied on.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-pb-purpose", "name": "communicationPurpose", "description": "Declared purpose of the message, against which permission scope is assessed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "de-pb-evaltime", "name": "permissionEvaluationTime", "description": "Time at which the permission state was checked, with explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "The consent record is deliberately kept outside this model: GDPR Article 7 gives it its own demonstrability and withdrawal lifecycle bound to a subject and purpose, not to any message. What the message owns is the basis code, purpose and evidence pointer captured at release, which are attributes of the message record and of the send event." }, { "id": "opt-out-and-suppression", "name": "Message-carried opt-out and suppression signals", "description": "Opt-out is partly a property of the message itself: a valid address for cessation requests must be present, and one-click unsubscribe requires an HTTPS URI, a specific post header and DKIM coverage of both headers, with receivers obtaining user consent before posting. Suppression outcomes then feed back into future send decisions.", "source_refs": [ "SRC-014", "SRC-009", "SRC-015" ], "questions": [ { "id": "q-oo-present", "text": "Does the message carry a valid, working cessation mechanism appropriate to its purpose and channel?", "kind": "requirement", "answer_data": [ "mechanism type", "target URI or address", "validity check outcome", "checking agent" ] }, { "id": "q-oo-integrity", "text": "Are the opt-out headers covered by the message's authentication signature so a receiver may act on them?", "kind": "security", "answer_data": [ "signature coverage indicator", "covered field list", "receiver action permitted" ] }, { "id": "q-oo-effect", "text": "When an opt-out is exercised, what scope does it suppress and within what deadline must it take effect?", "kind": "process", "answer_data": [ "suppression scope (endpoint, subject, purpose, all channels)", "effective deadline", "confirming record reference" ] }, { "id": "q-oo-precedence", "text": "How does a suppression signal interact with a still-valid permission record or a non-marketing message?", "kind": "exception", "answer_data": [ "precedence rule", "exempt message classes", "override authority" ] } ], "data_elements": [ { "id": "de-oo-mechanism", "name": "optOutMechanism", "description": "Type of cessation mechanism carried by the message.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-014" ] }, { "id": "de-oo-target", "name": "optOutTarget", "description": "Address or URI at which a cessation request is accepted.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-014" ] }, { "id": "de-oo-signed", "name": "optOutSignatureCoverage", "description": "Whether the opt-out fields are covered by a valid origin signature.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-oo-scope", "name": "suppressionScope", "description": "Extent of suppression resulting from an exercised opt-out.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-014" ] } ], "artifacts": [ { "id": "suppression-entry", "name": "Suppression entry", "description": "A record that a given endpoint, subject or purpose must not be contacted, created from an exercised opt-out or objection and consulted before any subsequent send.", "media_or_form": [ "suppression list entry", "objection record" ], "serial": true, "identity_strategy": "Suppressed endpoint or subject reference plus scope plus effective-from instant; where a master consent system exists, that system's suppression identifier is authoritative and this entry is a cached projection.", "source_refs": [ "SRC-015", "SRC-014", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "retention-and-disposal", "name": "Retention and Disposal", "description": "How long message records are kept, on what basis, and how they are redacted or destroyed.", "source_refs": [ "SRC-015", "SRC-020", "SRC-019", "SRC-014" ], "findings": [ { "id": "retention-appraisal-and-disposition", "name": "Retention basis, appraisal and disposition", "description": "Personal data must not be kept in identifiable form longer than necessary, while public-sector electronic messages are scheduled records that may be appraised by originator role rather than item-by-item. Traffic data carries its own erasure duty distinct from content. Retention is therefore multi-basis and can be assigned at different granularities.", "source_refs": [ "SRC-015", "SRC-020", "SRC-014" ], "questions": [ { "id": "q-rt-basis", "text": "What retention rule applies to this message, at what granularity, and who assigned it?", "kind": "authority", "answer_data": [ "schedule or rule reference", "granularity (item, role, category, thread)", "assigning role", "assignment time (RFC 3339)" ] }, { "id": "q-rt-parts", "text": "Do content, addressing metadata, traffic data and evidence share one retention period or different ones?", "kind": "retention", "answer_data": [ "component name", "retention period", "erasure trigger", "legal basis" ] }, { "id": "q-rt-trigger", "text": "What event starts the retention clock and what event ends it?", "kind": "lifecycle", "answer_data": [ "clock-start event", "clock-end event", "computed disposition date" ] }, { "id": "q-rt-hold", "text": "What suspends disposition, who may impose and lift that suspension, and how is it evidenced?", "kind": "exception", "answer_data": [ "hold identifier", "imposing authority", "scope", "imposition and release times (RFC 3339)" ] } ], "data_elements": [ { "id": "de-rt-rule", "name": "retentionRuleReference", "description": "Reference to the schedule item or policy rule governing this message's retention.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-015" ] }, { "id": "de-rt-period", "name": "retentionPeriod", "description": "Duration for which the component must be kept, per component where periods differ.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-014" ] }, { "id": "de-rt-due", "name": "dispositionDueDate", "description": "Computed date at which disposition becomes due.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020" ] }, { "id": "de-rt-hold", "name": "dispositionHold", "description": "Active suspension of disposition with its imposing authority and scope.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020", "SRC-015" ] } ], "artifacts": [ { "id": "disposition-instruction", "name": "Applied disposition instruction", "description": "The record binding a message or a class of messages to a retention rule, the computed disposition date, any holds, and the executed disposition outcome.", "media_or_form": [ "disposition instruction record", "schedule application entry" ], "serial": true, "identity_strategy": "Schedule item identifier from the authoritative records-management system plus the message or class identifier it is applied to; a UUID assigned by the adopting Dimension is used only where no records system identifier exists.", "source_refs": [ "SRC-020", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "redaction-and-deletion", "name": "Redaction, deletion and what survives", "description": "Deletion is rarely total: Matrix redaction removes content fields while preserving event identity, sender, timestamp and room, precisely so the conversation graph stays intact. Copies held by recipients and intermediaries are outside the sender's control, so the model must state which copies an erasure action actually reaches.", "source_refs": [ "SRC-019", "SRC-015", "SRC-014" ], "questions": [ { "id": "q-rd-scope", "text": "Which fields are removed by a redaction and which are deliberately preserved, and why?", "kind": "process", "answer_data": [ "removed field list", "preserved field list", "preservation rationale", "authorising role" ] }, { "id": "q-rd-reach", "text": "Which copies does a deletion or redaction actually reach, and which remain beyond the actor's control?", "kind": "access", "answer_data": [ "reachable custodians", "unreachable custodians", "notification obligation" ] }, { "id": "q-rd-evidence", "text": "What tombstone or audit evidence remains after destruction, and is it sufficient to prove lawful disposal?", "kind": "evidence", "answer_data": [ "tombstone fields retained", "audit record reference", "destruction time (RFC 3339)", "executing role" ] }, { "id": "q-rd-integrity", "text": "How does redaction interact with signatures, digests and delivery evidence over the redacted content?", "kind": "constraint", "answer_data": [ "invalidated evidence references", "mitigation", "record of the conflict" ] } ], "data_elements": [ { "id": "de-rd-action", "name": "erasureActionType", "description": "Type of erasure performed: redaction, content deletion, full destruction or anonymisation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-015" ] }, { "id": "de-rd-preserved", "name": "preservedFields", "description": "Fields deliberately retained after redaction to keep referential structure intact.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "de-rd-time", "name": "erasureTime", "description": "Time the erasure action was executed, with explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-015" ] }, { "id": "de-rd-authority", "name": "erasureAuthority", "description": "Role or instrument authorising the erasure.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-020" ] } ], "artifacts": [ { "id": "redaction-record", "name": "Redaction or destruction record", "description": "Evidence that an erasure action occurred, naming the target message, the fields removed, the surviving tombstone, the authority and the execution time.", "media_or_form": [ "redaction event", "destruction certificate", "disposal audit entry" ], "serial": true, "identity_strategy": "The redaction event's own identifier where the channel assigns one; otherwise target message identifier plus execution time plus executing role, since a message may be redacted more than once by different custodians.", "source_refs": [ "SRC-019", "SRC-020" ] } ], "inline_only_rationale": null } ] }, { "id": "access-and-disclosure", "name": "Access and Disclosure", "description": "Who holds a copy of a message, who may read it, and how disclosure is authorised and audited.", "source_refs": [ "SRC-014", "SRC-015", "SRC-010", "SRC-020" ], "findings": [ { "id": "copy-custody-and-access", "name": "Copy custody, access control and disclosure", "description": "Every message exists as several copies with different custodians and different visible content, because blind addressing is stripped on redistribution and confidentiality of communications restricts interception and access by anyone other than the users concerned. Access decisions therefore attach to a specific copy, not to an abstract message.", "source_refs": [ "SRC-010", "SRC-014", "SRC-015", "SRC-020" ], "questions": [ { "id": "q-ac-copies", "text": "Which custodians hold a copy of this message and how does each copy differ from the originator's?", "kind": "ownership", "answer_data": [ "custodian reference", "copy variant", "fields absent or masked", "holding system" ] }, { "id": "q-ac-rule", "text": "Who may read each copy by default, and which role grants exceptions?", "kind": "access", "answer_data": [ "default access rule", "granting role", "exception basis", "expiry of the grant" ] }, { "id": "q-ac-disclosure", "text": "Under what authority may a message be disclosed to a third party, and what is recorded about the disclosure?", "kind": "authority", "answer_data": [ "disclosure authority reference", "requesting party", "scope disclosed", "disclosure time (RFC 3339)" ] }, { "id": "q-ac-audit", "text": "What access and disclosure events must be audited, and how long is the audit trail itself kept?", "kind": "evidence", "answer_data": [ "auditable event types", "audit fields", "audit retention period", "audit custodian" ] }, { "id": "q-ac-subject", "text": "When the message contains personal data about a third party, how are their rights handled without breaching the correspondents' confidentiality?", "kind": "privacy", "answer_data": [ "affected subject reference", "request type", "redaction applied", "balancing decision record" ] } ], "data_elements": [ { "id": "de-ac-custodian", "name": "copyCustodian", "description": "Party or system holding this copy of the message and accountable for it.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-020" ] }, { "id": "de-ac-rule", "name": "defaultAccessRule", "description": "Baseline rule determining who may read this copy absent an explicit grant.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "de-ac-grant", "name": "accessGrant", "description": "Explicit, time-bounded grant of access to a party beyond the default rule.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-ac-disclosure", "name": "disclosureEvent", "description": "Record of a disclosure to a third party, with authority, scope and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-020" ] } ], "artifacts": [ { "id": "message-copy-holding", "name": "Message copy holding", "description": "A custodied instance of a message in one holding system, with its variant, access rule, grants, disclosure history and audit trail.", "media_or_form": [ "mailbox or store item", "archive holding entry", "access audit log" ], "serial": true, "identity_strategy": "Holding-system item identifier from the authoritative store where one exists; otherwise message identifier plus custodian reference. The message identifier alone is insufficient because it is shared across all copies.", "source_refs": [ "SRC-020", "SRC-015" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "compose-message", "name": "Compose message", "description": "Assemble a message record: mint or accept an identifier, set classification, build the typed content part tree and bind carried payloads by value or reference.", "inputs": [ "author and releasing agent references", "content parts with declared media types", "classification and priority codes", "payload references and digests" ], "outputs": [ "message record in draft state", "content part tree", "payload carriage entries" ], "preconditions": [ "Identifier generator and its uniqueness scope are known", "Each part has a declared media type", "Delegation is authorised where the releaser differs from the author" ], "effects": [ "A message record exists with a resolvable identifier and a validated part structure", "Origination time is recorded with an explicit offset" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-018", "SRC-007" ] }, { "id": "resolve-recipients", "name": "Resolve and classify recipients", "description": "Turn submitted recipient values into addressing entries with roles and visibility flags, retaining the submitted value alongside any resolved value.", "inputs": [ "submitted recipient values", "addressing role assignments", "channel address type" ], "outputs": [ "recipient addressing entries", "resolution outcomes", "expansion indicators" ], "preconditions": [ "Address type qualifier is known for each value", "Blind-addressing handling rule for the target channel is known" ], "effects": [ "Submitted and resolved addresses are both retained for correlation", "Entries requiring removal on redistribution are flagged" ], "source_refs": [ "SRC-004", "SRC-010", "SRC-001" ] }, { "id": "check-contact-permission", "name": "Check contact permission and suppression", "description": "Evaluate whether each recipient may be contacted for the declared purpose on the chosen channel, consulting the external permission record and the suppression entries.", "inputs": [ "recipient entries", "communication purpose", "channel identifier", "permission and suppression sources" ], "outputs": [ "per-recipient permission decision", "cited basis and evidence pointer", "blocked recipient list" ], "preconditions": [ "Purpose is declared", "Suppression source is reachable and its freshness is known" ], "effects": [ "Recipients without a valid basis are removed before release", "The cited basis and evaluation time are recorded on the message" ], "source_refs": [ "SRC-014", "SRC-015", "SRC-009" ] }, { "id": "submit-message", "name": "Submit message to a channel", "description": "Release the message into a channel, forming the envelope, selecting the delivery guarantee and recording the submission time and envelope identifier.", "inputs": [ "message record", "envelope originator and recipients", "requested guarantee level", "expiry interval" ], "outputs": [ "submission acknowledgement", "envelope identifier", "message state transition to in-progress" ], "preconditions": [ "Permission check has passed for every remaining recipient", "A valid cessation mechanism is present where the purpose requires one", "Return path for failure reports is set" ], "effects": [ "The message becomes irrevocable except where the channel supports withdrawal", "Envelope values are recorded separately from content" ], "source_refs": [ "SRC-002", "SRC-017", "SRC-014", "SRC-016" ] }, { "id": "record-handling-event", "name": "Record a handling event", "description": "Append a custody entry describing an agent that received, relayed or gatewayed the message, without altering existing entries.", "inputs": [ "handling agent identifier", "received-from value", "asserted timestamp", "trust boundary position" ], "outputs": [ "appended trace entry", "updated custody path" ], "preconditions": [ "The trace store is append-only", "Trust boundary of the recording organisation is defined" ], "effects": [ "Provenance of the message's path is extended", "Entries originating outside the trust boundary are marked untrusted" ], "source_refs": [ "SRC-002", "SRC-006", "SRC-019" ] }, { "id": "record-delivery-status", "name": "Record a delivery status report", "description": "Ingest a transport status report, map its outcome code to the model's classifier and correlate it to the originating submission and recipient entry.", "inputs": [ "status report", "reporting agent identifier", "original envelope identifier", "original recipient value" ], "outputs": [ "delivery status record", "updated per-recipient action", "mapping confidence" ], "preconditions": [ "Correlation identifiers are present or recoverable", "Outcome code registry is available" ], "effects": [ "Per-recipient delivery outcome is updated", "Contradictory or superseded reports are ordered by the supersession rule" ], "source_refs": [ "SRC-004", "SRC-012", "SRC-002" ] }, { "id": "register-delivery-evidence", "name": "Register registered-delivery evidence", "description": "Store a sealed evidence token from a registered delivery service, bind it to the payload digest and record the issuer, issuing policy and asserted qualified status.", "inputs": [ "evidence token", "issuer identifier and policy reference", "subject message identifier", "payload digest" ], "outputs": [ "registered delivery evidence artifact", "validation outcome", "presumption applicability note" ], "preconditions": [ "Evidence seal or signature can be validated", "Issuer identity resolves to a listed provider or is recorded as unverified" ], "effects": [ "The evidence is preserved with its verification state", "No legal presumption is asserted unless qualified status is evidenced" ], "source_refs": [ "SRC-013", "SRC-021", "SRC-007" ] }, { "id": "record-recipient-disposition", "name": "Record recipient disposition", "description": "Ingest a disposition notification or read receipt, correlate it to the message and recipient, and attach an explicit evidential-weight qualification.", "inputs": [ "disposition report", "original message identifier", "original recipient value", "recipient consent indicator" ], "outputs": [ "disposition notification record", "evidential weight classification" ], "preconditions": [ "Notification target was validated against the return path", "Recipient consent to report was obtained where required" ], "effects": [ "Disposition is recorded without any non-repudiation claim", "Absence of a report is not converted into a negative delivery fact" ], "source_refs": [ "SRC-005", "SRC-019" ] }, { "id": "evaluate-origin-authentication", "name": "Evaluate and stamp origin authentication", "description": "Run configured authentication methods, stamp the results with the authentication service identifier and remove untrusted assertions claiming to originate inside the trust boundary.", "inputs": [ "message record", "envelope originator", "authentication method configuration", "trust boundary definition" ], "outputs": [ "authentication results assertion", "removed forged assertions list" ], "preconditions": [ "Authentication service identifier is configured", "Trust boundary is explicitly defined" ], "effects": [ "Downstream consumers can attribute results to a named service", "Injected assertions from outside the boundary are deleted and audited" ], "source_refs": [ "SRC-006", "SRC-002" ] }, { "id": "assemble-conversation", "name": "Assemble conversation view", "description": "Group messages into a thread using channel-asserted identifiers where available and reconstruction from reference chains otherwise, marking derived membership as such.", "inputs": [ "message records", "thread identifiers", "reply and reference pointers", "reconstruction algorithm" ], "outputs": [ "conversation thread artifact", "membership assignments with assignment mode", "unresolved reference list" ], "preconditions": [ "Reconstruction algorithm is declared and versioned", "Access rules of the requesting party are known" ], "effects": [ "A conversation is presented with asserted and derived membership distinguished", "Messages the requester may not read are excluded rather than silently merged" ], "source_refs": [ "SRC-001", "SRC-008", "SRC-019" ] }, { "id": "apply-retention-disposition", "name": "Apply retention and compute disposition", "description": "Bind the message and its components to retention rules, compute disposition dates per component and honour any active hold.", "inputs": [ "message record", "retention rule references", "clock-start events", "active holds" ], "outputs": [ "applied disposition instruction", "per-component disposition due dates", "hold status" ], "preconditions": [ "The governing schedule or policy rule is resolvable", "Clock-start event has occurred" ], "effects": [ "Content, traffic data and evidence receive their own retention treatment", "Disposition is suspended while a hold is active" ], "source_refs": [ "SRC-015", "SRC-020", "SRC-014" ] }, { "id": "redact-or-destroy-message", "name": "Redact or destroy a message copy", "description": "Execute an authorised erasure on a specific copy, removing designated fields while preserving the structural tombstone, and record what evidence the action invalidates.", "inputs": [ "target copy reference", "erasure action type", "authorising instrument", "field removal specification" ], "outputs": [ "redaction or destruction record", "surviving tombstone", "invalidated evidence list" ], "preconditions": [ "No active hold applies to the target", "Authority for erasure is evidenced", "Reachable and unreachable copies have been identified" ], "effects": [ "Designated content is irrecoverable in the treated copy while references remain resolvable", "Integrity evidence covering removed content is marked invalidated rather than silently broken" ], "source_refs": [ "SRC-019", "SRC-015", "SRC-020" ] }, { "id": "disclose-message-copy", "name": "Disclose a message copy", "description": "Release a message copy to an authorised requester under a stated authority, applying required masking and writing an audit entry.", "inputs": [ "copy reference", "requesting party", "disclosure authority reference", "masking specification" ], "outputs": [ "disclosed extract", "disclosure event record", "audit entry" ], "preconditions": [ "Disclosure authority is valid and in scope", "Blind-addressing and third-party data have been assessed for masking" ], "effects": [ "Access outside the default rule is recorded with authority, scope and time", "Confidentiality obligations toward non-requesting correspondents are preserved" ], "source_refs": [ "SRC-014", "SRC-015", "SRC-010", "SRC-020" ] }, { "id": "relay-or-gateway-message", "name": "Deliver, relay or gateway", "description": "Accept envelope responsibility, add trace, relay unmodified or gateway with allowed transformations, expand aliases or lists according to their distinct DSN rules, and POST federated activities to inboxes.", "inputs": [ "Envelope reverse-path and forward-paths", "Message content", "Alias, mailing-list or collection expansion targets" ], "outputs": [ "Delivered, relayed or gatewayed copy", "Trace hop record", "Federated activity POSTed to target inboxes or sharedInbox" ], "preconditions": [ "Responsibility is accepted only after a success response at end of mail data" ], "effects": [ "Responsibility to deliver or report failure is accepted", "Trace is added; relays do not otherwise modify message data while gateways may transform", "Aliases and lists are expanded under their distinct DSN rules" ], "source_refs": [ "SRC-002", "SRC-023", "SRC-004" ] }, { "id": "withdraw-or-correct-message", "name": "Update, delete, undo or recall", "description": "Apply Update, Delete/Tombstone, Undo or a channel-specific recall; record entered-in-error or stopped for clinical communications; do not claim universal unsend.", "inputs": [ "Target object or message reference", "Mutation type" ], "outputs": [ "Update, Delete/Tombstone, Undo or channel-specific recall record", "Clinical entered-in-error or stopped status" ], "preconditions": [ "The channel supports the mutation and the actor owns the object" ], "effects": [ "Origin-side object updated, tombstoned or withdrawn", "No claim of universal unsend; federated or delivered copies may remain" ], "source_refs": [ "SRC-023", "SRC-010", "SRC-024" ] }, { "id": "reply-to-message", "name": "Reply or follow up", "description": "Create a new message with In-Reply-To/References or inReplyTo/inResponseTo, inherit or amend addressing, and trigger inbox forwarding when the origin cannot expand owned collections.", "inputs": [ "Parent and ancestor message identifiers", "Inherited or amended addressing" ], "outputs": [ "New message carrying In-Reply-To/References or inReplyTo/inResponseTo" ], "preconditions": [], "effects": [ "Thread edges extended in the conversation grouping", "Inbox forwarding triggered when the origin could not expand owned collections" ], "source_refs": [ "SRC-001", "SRC-023", "SRC-024" ] } ], "composition": [ { "target": "Agent and party model (person, organization, software agent)", "relation": "REFERENCE", "purpose": "Resolve author, releasing agent, recipients, custodians and evidence issuers to governed party entities instead of duplicating party attributes on the message.", "required": true, "source_refs": [ "SRC-001", "SRC-016", "SRC-010" ] }, { "target": "Contact endpoint and address-scheme model", "relation": "REFERENCE", "purpose": "Resolve submitted and final address values to durable endpoints and their scheme syntax; the message holds only the addressing entry as it stood for this message.", "required": true, "source_refs": [ "SRC-002", "SRC-008", "SRC-004" ] }, { "target": "Document and record model (carried payloads)", "relation": "REFERENCE", "purpose": "Resolve payloads carried by reference to independently governed documents; the message owns carriage mode, presented filename and digest only.", "required": false, "source_refs": [ "SRC-003", "SRC-016" ] }, { "target": "Consent and permission model", "relation": "REFERENCE", "purpose": "Supply the demonstrable consent or objection record cited as the permission basis at send time, including its withdrawal lifecycle.", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "target": "Retention schedule and disposition authority model", "relation": "REFERENCE", "purpose": "Supply the schedule items and role-based appraisal decisions that the message's applied disposition instruction points to.", "required": false, "source_refs": [ "SRC-020", "SRC-015" ] }, { "target": "Cryptographic key and trust-anchor model", "relation": "REFERENCE", "purpose": "Resolve signing and encryption keys and their trust anchors, which the message records only by reference so that key lifecycle stays out of scope.", "required": false, "source_refs": [ "SRC-006", "SRC-019" ] }, { "target": "Language and terminology model", "relation": "REFERENCE", "purpose": "Interpret language tags and charset declarations on textual parts without embedding language semantics in the message model.", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "target": "RFC 5322 Internet Message Format", "relation": "ALIGN", "purpose": "Align message identity, origination date, originator and destination roles, identification fields and resent semantics; alignment only, no conformance claimed.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "MIME (RFC 2045 and successors)", "relation": "ALIGN", "purpose": "Align the recursive content part tree, media typing, transfer encoding and intra-message content references.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "W3C ActivityStreams 2.0 Activity Vocabulary", "relation": "ALIGN", "purpose": "Align channel-neutral actor/object addressing and the normative stripping of blind audience properties on redistribution.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "HL7 FHIR R5 Communication", "relation": "ALIGN", "purpose": "Align the executed-communication record shape: status, category, priority, medium, sender/recipient, sent/received and payload-by-reference.", "required": false, "source_refs": [ "SRC-016" ] }, { "target": "OASIS MQTT 5.0", "relation": "ALIGN", "purpose": "Align delivery guarantee levels, message expiry, payload format indication and request-response correlation for machine-to-machine messaging.", "required": false, "source_refs": [ "SRC-017" ] }, { "target": "CNCF CloudEvents 1.0.2", "relation": "ALIGN", "purpose": "Align composite event identity (source plus id), payload schema identification and the RFC 3339 time requirement.", "required": false, "source_refs": [ "SRC-018" ] }, { "target": "eIDAS Regulation and ETSI EN 319 522 registered delivery evidence", "relation": "ALIGN", "purpose": "Align the named evidence event set and the conditions under which legal presumptions of sending, receipt, integrity and time may be asserted.", "required": false, "source_refs": [ "SRC-013", "SRC-021" ] }, { "target": "IANA Permanent Message Header Field Names registry", "relation": "ALIGN", "purpose": "Draw extension metadata names from the governed registry rather than minting local field names, preserving interoperability.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "Matrix Specification v1.16", "relation": "ALIGN", "purpose": "Align event-graph threading, reply relations and redaction semantics that preserve structural fields while removing content.", "required": false, "source_refs": [ "SRC-019" ] }, { "target": "Event and activity record model", "relation": "EXTEND", "purpose": "A message extends a generic occurrence record with directed addressing, delivery obligation and recipient-side evidence, which a plain event does not carry.", "required": false, "source_refs": [ "SRC-018", "SRC-010" ] }, { "target": "Audit and access-log mixin", "relation": "MIX-IN", "purpose": "Apply a shared audit pattern to access, disclosure and erasure of message copies rather than defining a message-specific audit format.", "required": false, "source_refs": [ "SRC-015", "SRC-020" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a single owner for the message record archetype and separate owners for evidence artifacts it does not itself issue, since delivery and disposition evidence originate outside the sender's control.", "The Dimension must declare, per channel it operates, which construct plays the envelope role and whether envelope and trace data are persisted, because retention duties for traffic data differ from those for content.", "The Dimension must publish its identifier-minting rule, its uniqueness scope and its reconstruction algorithm version for derived threads, so that asserted and derived structure remain distinguishable in every projection.", "The Dimension must register the permission and suppression sources it consults before release, with their freshness guarantees." ], "namespace_guidance": "Namespace the model under a stable message segment and keep bundle segments (content, addressing, conversation, transit, trust, custody) as the second level. Extension metadata names must be taken from the IANA permanent message header registry where an equivalent exists; locally minted names must live in a clearly separated vendor segment and must never shadow a registered name.", "registry_links": [ "IANA Permanent Message Header Field Names registry for header and metadata naming", "IANA SMTP Enhanced Status Codes registry for delivery outcome classification", "IANA media types registry as referenced by MIME for part typing", "National trusted lists for verifying asserted qualified registered-delivery providers" ] }, "canon_and_patch": { "canonicalization_rules": [ "All time values are RFC 3339 with seconds and an explicit numeric offset or Z; an unknown local offset is written as -00:00 and never silently normalised to Z.", "Event time and observation or ingestion time are stored as distinct fields; ordering uses the declared ordering basis, never a mixture of the two.", "Identifier fields keep the exact octets asserted by the generating system; case folding, angle-bracket stripping or domain lowercasing is recorded as a derived value, never applied in place.", "Content parts are addressed by ordered part path from the root entity; part paths are stable for the life of the message record and are not renumbered when a part is redacted.", "Integrity-relevant content is stored together with the canonicalisation rule under which its digest or signature was computed; if the stored form cannot satisfy that rule, the evidence is marked unverifiable rather than recomputed." ], "patch_rules": [ "Handling trace entries, delivery status records, evidence tokens and disposition notifications are append-only; a superseding record is added and linked, never an in-place edit.", "Corrections to a released message are represented as a typed derivation (correction, replacement, withdrawal) with its own identifier and time, never as mutation of the original record.", "Redaction removes designated content fields while preserving identity, sender, time and structural references, and writes a redaction record naming the removed fields and the invalidated evidence.", "Any patch that changes a field covered by an integrity signature must record the resulting verification failure explicitly.", "Permission basis and suppression scope are versioned with effective-from instants; a later evaluation never overwrites the basis cited at release." ], "compatibility_rules": [ "Adding a new classification axis, evidence type or channel-specific qualifier is backward compatible; removing or repurposing an existing one is breaking and requires a new model version.", "Narrowing the cardinality of an addressing or evidence element, or making an optional element required, is breaking.", "Mapping a channel outcome code to the model's outcome classifier must preserve the class distinction between permanent failure, transient failure and success; a mapping that collapses these classes is rejected.", "Projections may omit elements but must not reorder part paths or renumber trace positions.", "Alignment to an external standard may be added at any time; a conformance claim may only be added with cited evidence of assessment." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier: the message identifier, event identifier, evidence identifier or holding-system item identifier assigned by the system of record for that artifact.", "Governed global identifier or IRI: a registered scheme value such as a composite source plus id, or an endpoint IRI drawn from a governed address scheme.", "UUID or ULID assigned by the adopting Dimension, used only where neither of the above exists, and always recorded together with the minting rule.", "A date, timestamp, subject line or sender address is never an identifier; timestamps may order records but must not identify them." ], "timestamp_rule": "Every recorded instant uses RFC 3339 with seconds and an explicit offset or Z; where the originating local offset is unknown, -00:00 is used to state that fact. Event time and observation or ingestion time are recorded separately whenever the recording system did not itself produce the event.", "serial_naming_rule": "Serial artifacts are named by their parent identifier plus an intrinsic ordinal that reflects the source structure: content parts by ordered part path, recipient entries by recipient ordinal, trace entries by trace position (prepend order), and evidence or notification records by issuer plus issue-time sequence. Ordinals are never reused after redaction, and a serial name is never derived from a timestamp alone.", "integrity_rule": "Every artifact records the digest algorithm, digest value and canonicalisation rule under which its integrity evidence was computed, plus the outcome and time of the last verification. Storage or transport transformations that would invalidate that evidence are prohibited for artifacts carrying legal presumption; where a transformation is unavoidable, the artifact is marked unverifiable and the conflict is recorded rather than the digest recomputed." }, "policies": [ "Delivery, disposition and authentication reports are evidence of what a reporting agent asserted, not facts about what a recipient did; no non-repudiation or read-confirmation claim may be derived from a disposition notification, and the absence of a report may never be recorded as a negative delivery outcome.", "No message may be released for a purpose requiring permission until a per-recipient permission decision has been recorded with its basis, evidence pointer and evaluation time, and suppression entries have been consulted against both the submitted and the resolved address.", "Envelope, trace and other traffic data are retained only under a stated basis and for a stated period, independently of the retention applied to message content.", "Blind addressing is stripped before redistribution, and every stored copy declares which addressing variant it represents; a copy must never be presented as the originator's view when it is not.", "Authentication assertions claiming to originate inside the recording organisation's trust boundary but arriving from outside are deleted on ingest and the deletion is audited.", "Legal presumptions attached to registered delivery evidence are asserted only where the issuer's qualified status is evidenced by a trusted listing; otherwise the evidence is stored with the presumption marked as not established.", "Sender owns the origin message record; each recipient owns their received copy; consent subjects own their consent records.", "Contact for a non-transactional purpose requires a recorded lawful basis or demonstrable consent; withdrawal is as easy as grant and is evaluated before send.", "Bcc, bto and confidential forwarding addresses MUST NOT leak through other copies, public views or optional DSN fields.", "MDNs and similar receipts are opt-in, at most one per recipient per user agent, and MUST NOT be generated for an MDN.", "Relays accept responsibility to deliver or report failure; archives and legal holds override routine deletion but not the duty to record erasure requests." ], "crud": { "read": [ "Read is scoped to a specific message copy holding, not to the abstract message, because copies differ in visible content.", "Reading a copy outside the default access rule requires an explicit, time-bounded grant and produces an audit entry.", "Projections for non-participants must exclude blind addressing entries and other recipients' evidence records.", "Bulk read for compliance review requires a named authority reference recorded on each disclosure event." ], "create": [ "Creating a message record requires an identifier with a declared uniqueness scope and at least one typed content part.", "Creating an evidence, status or disposition record requires a resolvable correlation to a message identifier or envelope identifier and a named issuing agent.", "Creating a suppression entry requires a scope, an effective-from instant and the triggering signal.", "Records may not be created with a timestamp as their identifier." ], "update": [ "Message content and addressing are immutable after release; changes are expressed as typed derivations with new identifiers.", "Evidence, trace and notification records are append-only and are superseded rather than edited.", "Mutable fields are limited to governance state: lifecycle status, applied disposition instruction, holds, access grants and verification outcomes.", "Every update to governance state records the acting role and the RFC 3339 instant." ], "delete": [ "Deletion is executed per copy, and the record states which custodians the action could not reach.", "Redaction preserves identity, sender, time and structural references so that conversation graphs and evidence correlations remain resolvable.", "Deletion is refused while a disposition hold is active.", "Every deletion or redaction writes a record naming the removed fields, the authorising instrument, the executing role, the execution time and any integrity evidence thereby invalidated." ] }, "roles": [ { "name": "Message owner (originating sender)", "responsibilities": [ "Assert author and releasing-agent identity and any delegation basis", "Declare purpose, classification and sensitivity before release", "Ensure a valid cessation mechanism is present where the purpose requires one", "Hold the originator copy and its retention obligations" ] }, { "name": "Recipient custodian", "responsibilities": [ "Hold and govern the recipient copy, which legitimately differs from the originator's", "Control whether disposition notifications are sent, and obtain any required consent first", "Apply the copy's own retention rule and access decisions", "Raise objections and opt-out signals into the suppression source" ] }, { "name": "Channel and delivery service operator", "responsibilities": [ "Append handling trace entries without altering existing ones", "Issue delivery status records with registry-governed outcome codes", "Declare the delivery guarantee level and message expiry behaviour", "Where operating a registered delivery service, issue sealed evidence and preserve its verifiability" ] }, { "name": "Records and retention steward", "responsibilities": [ "Bind messages and their components to retention rules and compute disposition dates", "Impose and lift disposition holds with recorded authority", "Authorise and supervise redaction and destruction", "Ensure traffic data erasure duties are met separately from content retention" ] }, { "name": "Trust and authentication steward", "responsibilities": [ "Define the trust boundary and configure the authentication service identifier", "Remove and audit forged or externally injected authentication assertions", "Maintain verification schedules for integrity and evidence artifacts", "Record which claims may and may not be derived from each evidence type" ] }, { "name": "Permission and privacy steward", "responsibilities": [ "Maintain the permission and suppression sources consulted before release", "Assess third-party personal data and masking before disclosure", "Approve disclosure authorities and audit disclosure events", "Ensure withdrawal of permission is as easy as giving it and takes effect within the stated deadline" ] } ], "access": { "default_rule": "Deny by default. Access is granted only to the custodian of a specific message copy and to the parties addressed on that copy; any wider access requires an explicit, time-bounded, audited grant citing a named authority.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Compliance and records review may read full copies including delivery evidence and permission state under a recorded authority reference, with third-party personal data masked where not necessary to the purpose.", "Delivery service operators may read envelope and trace data required to operate the channel but not protected content.", "A data subject exercising access rights may receive their own personal data with other correspondents' content and blind addressing redacted, recording the balancing decision.", "Lawful-authority disclosure may override the default rule only with a cited instrument, a bounded scope and an audit entry.", "Automated agents may read message metadata for routing and deduplication without content access, provided the access is logged at scope granularity.", "Public or equivalent audience makes the message readable without authentication.", "Authorized compliance-archive reviewers may read full bodies, delivery evidence and consent state under audit.", "Bcc identities are visible only on copies that the Bcc policy allows.", "Reporting-MTA operators may read DSN diagnostic fields required to repair delivery, omitting confidential forward paths when policy requires." ], "audit_requirements": [ "Every read outside the default rule records requester, copy reference, scope, authority and RFC 3339 instant.", "Every disclosure, redaction, destruction and hold change records the acting role and the authorising instrument.", "Every removal of a forged authentication assertion records the removed value and the trust-boundary rule applied.", "Audit records are append-only, have their own declared retention period and custodian, and are excluded from the message's own disposition action.", "Failed and denied access attempts are audited with the same fields as successful ones.", "Record who read a compliance-archive view, when, and under which mandate.", "Record send, delivery-status, disposition, consent-grant, consent-withdraw, block, delete and erasure-request events with event time and ingestion time.", "Do not treat DSN or MDN as non-repudiation; log that they are forgeable." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Owner and maintainer role", "Alignment and conformance statement (alignments listed, conformance claimed only with cited assessment evidence)", "Identity and timestamp rules summary (identity priority order; RFC 3339 with explicit offset)" ], "read_order": [ "AGENTS.md — bootstrap contract identifying the model, its type and the four resolvable URLs", "Specification URL — scope, boundaries, bundle/layer/finding structure and the out-of-scope list before any structural change", "Storage type URL — the concrete projection in use (file tree, Git, MongoDB, MCP resource) and its canonicalisation rules", "Interface URL — how to read and write through the available access interface, including access scopes", "Processes URL — the governed functions, their preconditions and the audit obligations attached to each", "Coverage and known omissions — gaps, conflicts and regional assumptions, read before asserting any conformance or completeness claim" ] } }, "coverage": { "claim": "Covers the Message aggregate as a directed communication act and its record: identity and identifier provenance, classification and channel medium, content parts and carried payloads, originator authority, recipient addressing and resolution, envelope/content separation and handling trace, threading, typed derivation and request-response correlation, transmission state and distinct time points, three separately weighted delivery-evidence families, origin authentication and protection scope, and custody governance (permission basis at send, message-carried opt-out, retention, redaction, copy access). Evidence rests on the base pack's 21 primary sources plus ActivityPub carried in with the channel addition. Profile validation is real for email, federated social and clinical; chat, machine/event and non-electronic (postal) projections are asserted but not yet validated against a profile. This is not a claim of universal completeness and no conformance to any cited standard is asserted.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identifier generator, uniqueness scope, composite keys and secondary identifiers are separated (RFC 5322 msg-id uniqueness obligation, CloudEvents source+id, SMTP envelope identifier, Matrix event_id). Identity priority order is enforced in artifact_rules and a timestamp is explicitly barred as an identifier." }, { "dimension": "lifecycle", "status": "covered", "notes": "Two distinct state machines are modelled: the communication act (FHIR event status) and the per-recipient delivery attempt (DSN action values), plus expiry, withdrawal, correction and entered-in-error handling. Terminal versus retryable states are distinguished by enhanced-status class." }, { "dimension": "relationships", "status": "covered", "notes": "Reply pointers, ancestor chains, thread membership, typed derivations (forward, resend, correction, replacement, withdrawal) and request-response correlation are separated, with asserted versus reconstructed membership explicitly distinguished." }, { "dimension": "temporal", "status": "covered", "notes": "Origination, submission, arrival, receipt, disposition, evidence and observation times are separate elements; RFC 3339 with explicit offset is mandatory, -00:00 is reserved for unknown local offset, and clock ownership and trust are questioned per timestamp." }, { "dimension": "provenance", "status": "covered", "notes": "Append-only handling trace with per-hop asserted time and trust-boundary classification, plus authentication assertions attributable to a named service, plus payload digests bound to canonicalisation rules." }, { "dimension": "ownership", "status": "covered", "notes": "Sender owns the originator record, recipients own their copies, delivery operators own the evidence they issue, and records stewards own disposition. Copy custody is a first-class artifact because copies legitimately differ." }, { "dimension": "validation", "status": "covered", "notes": "Declared versus actual media typing, reference resolution status, contradictory status reports and supersession, mapping confidence for outcome codes, and integrity verification outcomes are all elicited." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with copy-scoped grants, five named exception classes, and audit requirements covering reads, disclosures, denials and forged-assertion removals. Access scopes span bundle, layer, finding and artifact." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Multi-basis retention separates content, addressing metadata, traffic data and evidence; holds suspend disposition; redaction preserves a structural tombstone; unreachable copies and invalidated integrity evidence must be recorded." }, { "dimension": "interoperability", "status": "covered", "notes": "Eleven external standards are recorded as alignments only, with registry-governed vocabularies for header names, media types and outcome codes, and channel-equivalence questions for non-mail envelopes and threading." }, { "dimension": "classification", "status": "covered", "notes": "Subject, category, priority and sensitivity are kept as independent axes with distinct handling effects, following FHIR and XMPP typing rather than a single collapsed type field." }, { "dimension": "addressing and routing", "status": "covered", "notes": "Envelope/content separation, role and visibility of recipient entries, blind-addressing stripping obligation, and submitted-versus-resolved recipient values with expansion and redirection." }, { "dimension": "delivery evidence", "status": "covered", "notes": "Three distinct evidence families are modelled separately with different issuers and evidential weight: transport status records, registered-delivery evidence with conditional legal presumption, and recipient disposition reports explicitly denied non-repudiation value." }, { "dimension": "authenticity and integrity", "status": "covered", "notes": "Origin authentication with trust-boundary deletion rule, protection scope (what stays observable under end-to-end encryption), canonicalisation-bound integrity and post-hoc verifiability." }, { "dimension": "permission and consent", "status": "covered", "notes": "Permission basis, purpose and evaluation time are captured on the message; the standing consent record and its withdrawal lifecycle are deliberately referenced to a sibling model. Message-carried opt-out mechanics including signature coverage are in scope." }, { "dimension": "privacy and confidentiality", "status": "covered", "notes": "Confidentiality of communications, traffic-data erasure, disposition-report disclosure risk, third-party personal data in disclosure, and masking obligations are addressed as constraints rather than as free-text notes." }, { "dimension": "measurement", "status": "gap", "notes": "Only structural quantities are modelled (part byte size, attempt count, participant count). Communication-effectiveness metrics such as open rates, latency distributions or engagement scoring are neither modelled nor supported by any cited primary source, and are marked a gap rather than presented as canonical." }, { "dimension": "spatial", "status": "not-applicable", "notes": "No cited primary source makes geographic location intrinsic to a message. Location enters only indirectly through jurisdiction of the permission basis and evidence presumption, which is handled under authority and constraint, and through ePrivacy location data, which belongs to the network-service sibling rather than the message." } ], "known_omissions": [ "ETSI EN 319 522-2 could not be retrieved directly (HTTP 403 on the ETSI deliver endpoint); its named evidence set is corroborated only by ETSI abstracts and by eIDAS Articles 43-44. The registered-delivery evidence finding should be re-verified against the normative text before any conformance statement.", "ISO 15489-1:2016 (records characteristics: authenticity, reliability, integrity, usability) was not directly retrievable and is deliberately not cited; retention and record-quality structure rests on GDPR and NARA instead, which is narrower in scope.", "Postal and broadcast channels are asserted to fit the same abstraction but are not evidenced here by a primary postal standard (for example UPU addressing or registered-mail rules). Non-electronic channel support is a structural gap.", "Group and multi-party conversation governance (room membership rights, moderation, ejection and their effect on message visibility) is only partially covered; Matrix state resolution and power levels were reviewed but not modelled, as they arguably belong to a group/room sibling model.", "Machine-agent negotiation semantics beyond request-response correlation (capability advertisement, protocol version handshakes, agent-to-agent authorisation tokens) are out of scope and not evidenced.", "Message translation, transcoding and rendering fidelity across channels (for example gatewaying rich content to plain text) is not modelled beyond alternative-part selection.", "Anti-abuse handling (spam classification, quarantine, greylisting) is treated only through outcome codes, not as a governed decision record.", "Universal Postal Union addressing and physical delivery evidence were not fetched.", "Matrix Client-Server event IDs, XMPP stanza IDs, JMAP, IMAP flags and RFC 8621 were not fetched as primary sources.", "S/MIME, OpenPGP, DKIM, SPF and DMARC are relevant integrity evidence but were not primary-fetched; treated as alignment gaps.", "ISO 15489 / MoReq records-management schedules are not primary-supported.", "CAN-SPAM, ePrivacy/PECR and TCPA unsolicited-communication rules are region-specific and not fully sourced here.", "RFC 4865 future-release, RFC 6530-6533 internationalized email, and RFC 8058 one-click unsubscribe were not fetched.", "SMS, RCS, mobile push and proprietary chat receipts lack a single primary mapping.", "End-to-end encrypted envelopes (MLS, server-side fanout of ciphertext) are out of evidence for this run." ], "conflicts": [ "Threading is genuinely inconsistent across standards: mail has no thread field and requires reconstruction from References, XMPP carries an opaque thread with a parent, and Matrix defines threads by relation to a root event. The model records assignment mode rather than forcing one mechanism, so cross-channel thread identity cannot be assumed equivalent.", "Read evidence conflicts in strength: RFC 8098 explicitly denies non-repudiation and warns of forgery, while eIDAS grants rebuttable presumptions to qualified registered delivery. Treating a read receipt and a consignment evidence token as the same 'delivered/read' status would be a material error, so the model keeps them as separate artifacts with an explicit evidential-weight element.", "Envelope and header originator routinely disagree by design (forwarding, mailing lists, bounce null reverse-path). Any model that stores a single 'sender' loses the ability to reason about authentication alignment; this model stores both and records which was authenticated.", "Blind-addressing handling differs: ActivityStreams places a MUST on intermediaries to remove bto and bcc, while RFC 5322 leaves Bcc handling to the originating agent. The model therefore treats the stored copy variant as required data rather than assuming a canonical addressing view.", "Deletion semantics conflict with integrity evidence: redaction that preserves referential structure necessarily invalidates signatures and digests over removed content. The model requires the conflict to be recorded rather than resolved by recomputation.", "CloudEvents identity is composite (source + id) whereas RFC 5322 identity is single-valued and globally unique. Mapping between them is lossy in both directions and is flagged as a mapping-confidence element rather than silently normalised.", "RFC 5322 Date uses IMF date-time; Activity Streams requires RFC 3339 with optional omitted seconds. This model stores RFC 3339 and treats IMF Date as an alignment, not identical syntax.", "SMTP envelope reverse-path need not equal header From; using header From as the responsible sender is a known error.", "DSN action delivered is terminal and does not mean read; MDN displayed does not mean understood; FHIR completed is a clinical-record status. Do not unify these codes.", "Message-ID identifies content; Original-Envelope-Id identifies submission; ActivityPub Create id and object id are distinct; local store keys are another layer.", "ActivityPub Delete does not retract every federated copy; email has no standard recall. Claiming unsend would be a false conformance.", "Bcc confidentiality versus DSN Final-Recipient and mailing-list MDN leakage are unresolved operational tensions; sites MAY omit fields.", "GDPR erasure rights conflict with legal hold and medical-record retention; both must be representable without implying a single global outcome.", "FHIR Communication is a record that sharing occurred, including failures, and is not the on-the-wire message object." ], "regional_assumptions": [ "Permission, opt-out and confidentiality structure is grounded in EU instruments (ePrivacy Directive as amended, GDPR). Other regimes differ materially — notably opt-out-based rather than opt-in-based commercial email rules in some jurisdictions — so the permission basis code list must be jurisdiction-parameterised by the adopting Dimension.", "Registered-delivery legal presumption is an EU construct tied to qualified trust services under eIDAS and to national trusted lists. Outside that framework, evidence tokens carry no presumption and the qualified-status element must be recorded as not established.", "Role-based appraisal of electronic messages (Capstone, GRS 6.1) is US federal-sector guidance cited as evidence that message disposition can be assigned by originator role. It is not a general legal requirement and must not be applied as one elsewhere.", "Address syntax and internationalisation assumptions follow IETF mail and XMPP conventions; locales relying on non-IETF addressing (for example certain national e-delivery or postal schemes) require an address-type qualifier that the model provides but does not enumerate.", "Retention periods are left unbound because they derive from sector and jurisdiction; only the structure (per-component periods, clock-start events, holds) is asserted as general.", "GDPR Article 7 is assumed for EEA-relevant contact consent; other regions may rely on contract, legitimate interest or sectoral anti-spam law instead.", "SMTP FQDN and DNS MX routing assume Internet mail; isolated intranets and non-TCP transports are allowed by RFC 5321 but not detailed here.", "ActivityPub HTTPS-dereferencable actor and object ids assume a web-origin server namespace.", "FHIR Communication is typical of HL7-adopting health systems and is not a global clinical mandate.", "Default MDN suppression reflects RFC 8098 privacy guidance, which some enterprise mail systems override by policy." ], "adversarial_checks": [ "Counterexample sought for the claim that a message always has one sender: mailing-list expansion, resent messages and null-reverse-path bounce reports each break it. Result — the model separates author, releasing agent, envelope originator and redistributing party rather than a single sender field.", "Counterexample sought for the claim that delivery status implies receipt: RFC 8098 states MDNs are forgeable and lossy, and DSN 'relayed' explicitly disclaims further responsibility. Result — evidential weight is a required consideration and absence of a report is barred from being recorded as non-delivery.", "Attractive-but-unsupported structure rejected: a unified 'channel' entity with provider, credentials and contract was proposed by the previous version, but no cited primary source makes provider or contract intrinsic to message semantics. Result — only the medium/channel-type code and the envelope-equivalent construct are retained; provider entities are referenced to a sibling.", "Attractive-but-unsupported structure rejected: a first-class 'consentRecord' inside the message model. GDPR Article 7 binds consent to a subject and purpose with its own withdrawal lifecycle independent of any message, so owning it here would duplicate a sibling and mislocate the demonstrability duty. Result — only the basis cited at release and message-carried opt-out mechanics are retained.", "Attractive-but-unsupported structure rejected: an 'address' entity with owner and verified flag. Address values have meaning only inside a channel's scheme, and the same string may denote different endpoints over time. Result — the message owns the addressing entry as it stood for this message; the durable endpoint is referenced.", "Boundary stress test on attachments: if the message owned the carried document, redacting the message would destroy an independently governed record. MIME and FHIR both treat the payload as either inline or a reference. Result — the message owns carriage mode, presented filename and digest only.", "Storage-neutrality test: every finding was re-read for hidden format assumptions. Header-field language was replaced by role and structure language (part path, addressing entry, trace position) so the model projects equally onto a document store, an append-only log, a Git tree or an MCP resource without semantic loss.", "Identity stress test: checked whether any artifact would be identified by a date or subject line. Content parts, trace entries, evidence tokens and copy holdings all received structural or master-system identity instead, and the artifact rules bar timestamp-only identity explicitly.", "Could a forged DSN or MDN be treated as non-repudiation? No; RFC 3464 and RFC 8098 document forgery; evidence-grade remains unverified unless independently corroborated.", "Could Bcc or confidential autoforward addresses leak via DSN Remote-MTA, Final-Recipient or propagated MDN requests? Yes; optional fields MUST be omissible and list exploders SHOULD NOT propagate MDN requests.", "Could this model claim email recall because ActivityPub has Delete? No; recall-supported is per channel and defaults false for IMF/SMTP.", "Could a date or sent-at be used as a message identifier? Forbidden by identity priority.", "Could consent withdrawal be modelled as deleting the grant evidence? Forbidden; withdrawal is a timestamped event and prior lawful sends remain explicable.", "Could FHIR AuditEvent replace Communication for clinician-to-clinician letters? No; HL7 distinguishes reviewable Communication in the patient record from system audit.", "Could likes, follows or presence pings be stored as messages? Only if they are themselves the communication unit; otherwise they belong to social-activity or session neighbors." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Both providers independently classify WM-REC-003 as an aggregate whose root is the message record and whose parts (content parts, addressing entries, handling-trace entries, evidence records, copy holdings) have no independent identity outside it, so entry kind is settled without split or merge. The adopted boundary is the base (claude) boundary, which is narrower than grok's: the party/agent master, the durable contact-endpoint registry with owner and verification state, the standing consent record with its own grant/withdraw lifecycle, the carried document's own lifecycle, channel-provider service entities and key material stay in sibling models. Grok pulled endpoint, provider and consent masters inside scope; that widening is rejected because each carries an independent lifecycle and custodian, and the base already records the message-scoped projection of each (addressing entry as it stood, medium code, permission basis cited at release)." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude as base", "rationale": "Six boundary notes each pairing a named neighbor with a sourced distinction, an explicit out-of-scope list, and adversarial checks that already rejected channel-provider, consent-record and address entities give the clearest complete boundaries. Grok's larger artifact count and higher self-confidence do not offset a scope statement that absorbs three sibling masters." }, { "concept": "Entry kind", "disposition": "accepted as aggregate", "rationale": "Both providers agree, and the part set (content parts, addressing entries, trace entries, evidence records, copy holdings) has no identity or custodian independent of the message record, which is the aggregate test. No split or merge is warranted." }, { "concept": "Channel type and medium classifier", "disposition": "accepted from grok into message-core-and-classification", "rationale": "Materially missing from the base despite being presupposed by six of its questions, and independently evidenced by FHIR Communication.medium and the RFC 5321 system-role taxonomy. Narrowed on import so the provider service entity stays a sibling reference." }, { "concept": "Durable endpoint entity with owner and verification state", "disposition": "rejected", "rationale": "Grok's endpoint-address finding places the address master inside the aggregate. The base already owns the addressing entry as it stood for this message, and an address value has meaning only inside a channel scheme and may denote different endpoints over time, so verification state belongs to the contact-endpoint sibling." }, { "concept": "Standing consent record and its withdraw lifecycle", "disposition": "rejected", "rationale": "Grok's contact-consent finding and consent-record artifact duplicate a sibling whose demonstrability duty is bound to a subject and purpose, not to any message. The base keeps the message-scoped projection — basis cited at release, evaluation time, evidence pointer — plus message-carried opt-out mechanics, which is the correct split." }, { "concept": "Envelope versus content and responsibility handoff", "disposition": "finding rejected as duplicative; handoff captured via function", "rationale": "Grok's envelope-and-handoff overlaps the base envelope-content-separation and handling-trace findings almost entirely. The one non-duplicative element, the acceptance-of-responsibility point, is carried by the imported relay-or-gateway-message function instead of a second envelope finding." }, { "concept": "Null reverse-path loop prevention", "disposition": "deferred", "rationale": "The rule that DSNs and MDNs use a null reverse-path to prevent notification loops is a real normative element the base does not carry, but it is a single mechanism rather than a finding and would need its own evidence review before placement in envelope-and-handling-path." }, { "concept": "Provenance and integrity finding from grok", "disposition": "rejected as duplicative, one element deferred", "rationale": "Trace hops, reporting-agent forgeability, checksums and authentication results are already split across three base findings with more precision. Only origin-dereference verification of federated objects is novel, and importing the whole finding to obtain it would triple-duplicate the base." }, { "concept": "Recall, update, delete and tombstone finding", "disposition": "rejected as duplicative; act imported as a function", "rationale": "Withdrawal guarantee is elicited by q-der-recall, tombstone survival by q-rd-scope and q-rd-reach, erroneous states by q-st-erroneous, and Block by q-oo-precedence. The genuine gap was functional, not structural, so only the function is imported." }, { "concept": "Grok duplicates of core base findings", "disposition": "rejected", "rationale": "message-identity, originator-and-lifecycle, multipart-entities, attachment-pointers, reply-and-thread, audience-addressing, delivery-status and copy-ownership are each covered by an equal or more decomposed base finding. Grok merges concerns the base keeps separate (originator versus lifecycle versus time points), and merging back would lose that separation." }, { "concept": "Claude-only structure under challenge", "disposition": "retained", "rationale": "Registered-delivery evidence, delivery-guarantee and duplicate control, request-response correlation, distinct time points and origin authentication are each grounded in primary sources grok simply did not fetch (eIDAS/ETSI, MQTT/CloudEvents, RFC 8601). Absence from grok is a coverage difference, not counter-evidence." }, { "concept": "Function set", "disposition": "three grok functions accepted, five rejected", "rationale": "Accepted functions fill acts the base findings presuppose but no base function performs. compose-and-send, record-delivery-status, record-disposition, archive-hold-or-erase duplicate base functions, and grant-or-withdraw-consent belongs to the rejected consent sibling." }, { "concept": "Merged source list", "disposition": "base 21 sources plus ActivityPub carried by the addition", "rationale": "The channel addition depends on W3C ActivityPub, which is absent from the base pack, so the synthesizer must carry it as a new tier-1 source subject to the same live-URL and version verification as the rest." }, { "concept": "GDPR citation quality", "disposition": "base EUR-Lex citation retained; grok mirror not carried", "rationale": "Grok cites gdpr-info.eu, a third-party mirror, as a tier-1 primary source. The base cites EUR-Lex directly. No grok GDPR-derived material is imported, so the mirror does not enter the merged pack." }, { "concept": "Overall confidence", "disposition": "medium", "rationale": "The base self-reports medium, one cited normative text could not be retrieved, and profile validation is uneven across channels. Grok's high self-rating rests on a narrower source base and a wider, less disciplined boundary, so it does not raise the merged rating." } ], "publicationHolds": [ "Live-URL and version-pin verification for all 21 base sources plus the ActivityPub source newly carried by the channel-type-and-medium addition; no source in the merged pack has been re-fetched during adjudication.", "ETSI EN 319 522-2 could not be retrieved (HTTP 403 on the ETSI deliver endpoint) and its named evidence set is corroborated only by abstracts and eIDAS Articles 43-44; the registered-delivery-evidence finding must be checked against the normative text before publication and before any conformance or legal-presumption statement.", "FHIR R5 Communication is pinned inconsistently across providers (base states Standard for Trial Use, grok states v5.0.0 dated 26 March 2023); reconcile the maturity designation and version pin against hl7.org before publishing findings that rely on it.", "Multi-profile validation is incomplete: the model is evidenced against email, federated social and clinical communication, while chat (XMPP, Matrix), machine and event messaging (MQTT, CloudEvents) and non-electronic channels are asserted projections. Run at least one chat, one machine/event and one postal domain profile before publication.", "Regional parameterisation must be stated on the published draft: permission and opt-out structure is EU-grounded (ePrivacy, GDPR), registered-delivery presumption is an eIDAS qualified-trust-service construct, and role-based appraisal is US federal guidance (NARA Capstone, GRS 6.1) that must not be presented as a general legal requirement.", "The imported channel-type-and-medium finding must be checked after synthesis to confirm it carries only the medium classifier and hop-role taxonomy, with no provider service entity, credentials or contract attributes leaking in against the adopted boundary." ], "deferredResearch": [ "ActivityPub inbox-forwarding (the ghost-reply obligation, where a server forwards an activity to collections it owns because the origin could not expand them) — decide whether this is a distinct distribution mechanism belonging in recipient-resolution or a projection detail of collection addressing.", "Origin-dereference verification of federated objects (fetching the object at its origin identifier and comparing) as an authenticity mechanism distinct from stamped authentication results — evaluate for placement in the origin-authentication layer alongside RFC 8601 assertions.", "Null reverse-path loop prevention for delivery and disposition notifications, and the exact point at which a hop assumes the obligation to deliver or report failure, as candidate elements of envelope-and-handling-path.", "Tombstone and Undo-versus-Delete lifecycle semantics from ActivityPub, including whether a deleted-object placeholder is a state of the message record or a separate artifact, and how it relates to Matrix redaction already modelled in the base.", "Postal and physical delivery profiles (UPU addressing, registered-mail evidence) and mobile channels (SMS, RCS, push receipts), both of which are asserted to fit the abstraction with no primary source in either provider pack.", "Signature and authentication primary sources not fetched by either provider — DKIM, SPF, DMARC, S/MIME, OpenPGP — needed before origin-authentication and protection findings can move beyond alignment-level claims.", "Records-management standards not primary-supported in either pack (ISO 15489-1 record characteristics, MoReq) as a check on the retention, appraisal and disposition structure currently resting on GDPR and NARA alone.", "Group and multi-party conversation governance (room membership, moderation, ejection and their effect on message visibility) — confirm whether it belongs to a group/room sibling or requires a message-side visibility element.", "A sensitivity and confidentiality label code system from a primary information-security standard, which grok records as an open gap and the base carries only as a classification axis without a governed vocabulary." ] }, "statistics": { "sources": 25, "bundles": 6, "layers": 15, "findings": 27, "questions": 111, "artifacts": 16, "functions": 16 } }