# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-23T02:36:57Z", "synthesisSha256": "478f7f042a8e07f35841d570a062d74561e5bb0eaefc1644c7a1b370177a7abb", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-XCT-002", "registryId": "vr.wm-xct-002", "name": "Access Contract / Consent", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.ACC" ], "tags": [ "access", "contract", "consent", "xct.acc" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-xct-002-access-contract-consent/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-002", "model": { "registry_id": "vr.wm-xct-002", "model_id": "WM-XCT-002", "name": "Access Contract / Consent", "entry_kind": "mixin", "purpose": "Provide a format-neutral, machine-readable instrument of permission to read: which party permits which reader to read which slice of data, for which declared purpose, under which conditions and duties, until when, on what evidence of assent, and how that permission is verified, changed and ended.", "scope_statement": "This mixin is attached to any world-model entry whose data may cross an ownership or accountability boundary. It owns the permission instrument (parties, scope selection, purpose, action, constraints, duties), the optional consent act and its evidence, the instrument lifecycle and its termination propagation, and the minimal decision surface by which a holder asks whether a specific read is covered. It does not own the data being shared, the shape in which it leaves, the log of exercises, or enforcement casework. Consent is modelled as one possible basis of a grant, not as a mandatory precondition, because lawful permission can also rest on contract, statute or court order.", "in_scope": [ "The grant instrument: grantor, grantee, scope clauses, declared purpose, permitted action, validity window, machine-evaluable constraints and grantee duties", "The consent act where one exists: expression, capture context, notice version, validity elements, evidence record and portable receipt", "Authority and capacity to grant, including representative, guardian and delegate capacity, and the verification outcome of that authority", "Instrument lifecycle: proposal, activation, amendment, supersession, suspension, expiry, withdrawal and revocation, with explicit effective times", "Termination propagation to downstream holders and evidence of cutoff, deletion or return", "The coverage-decision request/response surface and its outcome vocabulary, including unevaluable outcomes", "Conflict and precedence handling across multiple applicable instruments", "Provenance, integrity and canonical form of instrument and consent records", "Retention and erasure of the instrument and its evidence", "Jurisdictional parameters that vary the instrument (governing law, age thresholds, conditioning rules, transfer conditions)" ], "out_of_scope": [ "Ownership, title and delegation registries: authority is verified against them, not defined here", "Disclosure shape, redaction, masking and projection policies: referenced by identifier only", "The access audit log of individual read exercises", "Enforcement cases, sanctions and breach handling arising from violations", "Identity proofing and authentication of parties; the model consumes party identifiers and assurance levels", "Schemas, semantics or quality of the payload data itself", "Write, modify, delete and licensing/royalty permissions; the normative core is read/disclosure", "Token, key and protocol mechanics of OAuth, UMA or similar; these are projections of the decision surface", "Adjudication of whether a non-consent legal basis is lawful" ], "boundary_notes": [ { "neighbor": "Ownership and delegation model (legacy S1, world.ownership)", "distinction": "That model holds who holds title and who may act for whom. This model records the asserted authority basis, a reference to the record relied on, and the verification outcome and time. A grant whose authority basis fails verification is invalid here but the correction happens there.", "source_refs": [ "SRC-003", "SRC-007", "SRC-011" ] }, { "neighbor": "Disclosure scope / projection policy model (legacy S3)", "distinction": "A scope clause designates which objects are covered; it never describes the shape in which they leave. The shape is a reference to a projection policy identifier resolved in the sibling model.", "source_refs": [ "SRC-001", "SRC-007" ] }, { "neighbor": "Access audit model (legacy S4)", "distinction": "This model holds terms and current state; every exercise of a grant, and every decision rendered, is an event recorded in the audit model. Only the decision correlation identifier is retained here.", "source_refs": [ "SRC-008", "SRC-014" ] }, { "neighbor": "Access enforcement model (legacy S7)", "distinction": "Duties and their deadlines are declared here; detection of breach, escalation and remedy are cases there. This model records only whether a duty was discharged and on what evidence.", "source_refs": [ "SRC-001", "SRC-013" ] }, { "neighbor": "Legal-basis and lawfulness model", "distinction": "Consent is one legal basis among several. This mixin can carry a declared basis and, where the basis is consent, the full consent apparatus; it does not decide whether a non-consent basis is validly invoked.", "source_refs": [ "SRC-003", "SRC-006" ] }, { "neighbor": "Policy decision and enforcement infrastructure (XACML PDP/PEP, UMA authorization server)", "distinction": "This model defines the decision inputs, outcome vocabulary and returned obligations. Combining-algorithm implementation, ticketing and token formats belong to the enforcement infrastructure and are alignments, not content.", "source_refs": [ "SRC-008", "SRC-009", "SRC-010" ] }, { "neighbor": "Privacy notice / transparency model", "distinction": "The notice text and its version live in the transparency model. This model references the exact notice version shown at capture time and stores an immutable snapshot only as evidence.", "source_refs": [ "SRC-005", "SRC-015" ] } ] }, "sources": [ { "id": "SRC-001", "title": "ODRL Information Model 2.2", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/odrl-model/", "version_or_date": "W3C Recommendation, 15 February 2018", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Normative structure of a permission instrument: Policy/Set/Offer/Agreement, Rule/Permission/Prohibition/Duty, Asset and AssetCollection, Party and PartyCollection, Action, Constraint and LogicalConstraint, and the uid, target, assigner, assignee, action, constraint, duty, obligation, conflict, inheritFrom and profile properties." }, { "id": "SRC-002", "title": "ODRL Vocabulary & Expression 2.2", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/odrl-vocab/", "version_or_date": "W3C Recommendation, 15 February 2018", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Action terms (read, use, index, derive, aggregate, anonymize, archive, distribute), constraint left operands (dateTime, elapsedTime, purpose, recipient, spatial, count, event), operators, party functions including consentingParty, and policy subclasses Privacy, Request, Assertion, Ticket." }, { "id": "SRC-003", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679", "version_or_date": "OJ L 119/1, 4 May 2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Art 4(11) definition of consent; Art 5(1)(b) purpose limitation and 5(1)(e) storage limitation; Art 6(4) compatibility factors; Art 7 conditions including demonstrability and withdrawal without retroactive effect; Art 8 child's consent; Art 9(2)(a) explicit consent; Art 17 erasure; Art 19 notification of recipients; Art 30 records of processing." }, { "id": "SRC-004", "title": "Guidelines 05/2020 on consent under Regulation 2016/679, Version 1.1", "organization": "European Data Protection Board", "url": "https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en", "version_or_date": "Version 1.1, adopted 4 May 2020", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Authoritative interpretation of the four validity elements (freely given, specific, informed, unambiguous), explicit consent, granularity and separation, demonstrating consent, withdrawal being as easy as giving, and children's consent." }, { "id": "SRC-005", "title": "ISO/IEC TS 27560:2023 Privacy technologies — Consent record information structure", "organization": "International Organization for Standardization / International Electrotechnical Commission", "url": "https://www.iso.org/standard/80392.html", "version_or_date": "Technical Specification, published August 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Interoperable information structure for consent records and receipts, including record identifier, notice reference, processing details, consent events and lifecycle. The catalogue entry was retrieved; the normative text is paywalled, so field-level detail is grounded in SRC-016 which maps it explicitly." }, { "id": "SRC-006", "title": "Data Privacy Vocabulary (DPV) Version 2.1", "organization": "W3C Data Privacy Vocabularies and Controls Community Group", "url": "https://w3c-cg.github.io/dpv/2.1/dpv/", "version_or_date": "Final Community Group Report, 16 March 2025", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Consent status vocabulary (Requested, Given, Refused, Withdrawn, Expired, Revoked, Invalidated, Unknown), ConsentRecord/ConsentReceipt/ConsentNotice concepts, entity roles, purposes, processing operations and legal bases. Explicitly not a W3C Standard." }, { "id": "SRC-007", "title": "HL7 FHIR Release 5: Consent resource", "organization": "Health Level Seven International", "url": "https://www.hl7.org/fhir/consent.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 2, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Working example of a deployed permission instrument: grantor, grantee, manager, controller, regulatoryBasis and policyBasis, verification block, decision permit/deny, and nested provisions with period, actor, action, securityLabel, purpose, dataPeriod, data and expression." }, { "id": "SRC-008", "title": "eXtensible Access Control Markup Language (XACML) Version 3.0", "organization": "OASIS", "url": "https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html", "version_or_date": "OASIS Standard, 22 January 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Separation of PAP, PDP, PEP, PIP and context handler; PolicySet/Policy/Rule with Target, Condition and Effect; obligation and advice expressions; combining algorithms; and the four decision values Permit, Deny, Indeterminate and NotApplicable." }, { "id": "SRC-009", "title": "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization", "organization": "Kantara Initiative", "url": "https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html", "version_or_date": "Kantara Recommendation, 2018", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Party-to-party authorization where the resource owner sets policy asynchronously and in advance; roles of resource owner, requesting party, client, resource server and authorization server; permission ticket, requesting party token and claims gathering as the runtime projection of a standing grant." }, { "id": "SRC-010", "title": "RFC 9396: OAuth 2.0 Rich Authorization Requests", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9396.html", "version_or_date": "Standards Track, May 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "authorization_details structure with type, locations, actions, datatypes, identifier and privileges; requirement that the granted details be returned in token responses and introspection, which is the interoperable projection of a scope clause and permitted action." }, { "id": "SRC-011", "title": "45 CFR 164.508 — Uses and disclosures for which an authorization is required", "organization": "U.S. Department of Health and Human Services (Code of Federal Regulations, eCFR)", "url": "https://www.ecfr.gov/api/renderer/v1/content/enhanced/current/title-45?part=164§ion=164.508", "version_or_date": "Current eCFR text, retrieved 23 August 2026", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "A non-EU counterexample instrument: required core elements (specific and meaningful description of information, authorised discloser, recipient, purpose, expiration date or event, signature and date), required statements on revocation, conditioning and redisclosure, defects that void an authorization, compound-authorization limits, and retention under 164.530(j)." }, { "id": "SRC-012", "title": "Verifiable Credentials Data Model v2.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "issuer, credentialSubject, validFrom/validUntil, credentialStatus for revocation and suspension, credentialSchema, termsOfUse, evidence, proof and refreshService — the pattern for a portable, independently verifiable receipt with a checkable status." }, { "id": "SRC-013", "title": "Data Use Ontology (DUO)", "organization": "Global Alliance for Genomics and Health / EMBL-EBI (OBO Foundry)", "url": "https://github.com/EBISPOT/DUO", "version_or_date": "OBO Foundry ontology, date-versioned releases, CC BY 4.0; ontology IRI http://purl.obolibrary.org/obo/duo", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "A governed, deployed vocabulary of permitted-purpose codes and use modifiers (general research use, disease-specific, no commercial use, ethics approval required, publication required, collaboration required, geographic and institutional restrictions, time limits, return to database) that shows purposes and duties are coded reference data, not free text." }, { "id": "SRC-014", "title": "Regulation (EU) 2022/868 on European data governance (Data Governance Act)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R0868", "version_or_date": "OJ L 152/1, 3 June 2022", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Art 12 duties of data intermediation providers (neutrality, no use of exchanged data for other purposes, tools for obtaining and withdrawing consent, logging) and Art 25 European data altruism consent form: modular, sector-customisable and machine-readable, with easy withdrawal." }, { "id": "SRC-015", "title": "Consent Receipt Specification v1.1.0", "organization": "Kantara Initiative", "url": "https://kantarainitiative.org/download/consent-receipt-specification/", "version_or_date": "Kantara Initiative Recommendation v1.1.0, 30 December 2019", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Establishes the receipt as a distinct, grantor-facing artefact with its own identifier, timestamp, collection method, language, jurisdiction, controller and policy-URL fields. Only the publication page was retrievable, so it is cited for the existence, version and role of the receipt pattern rather than for field-level normative detail." }, { "id": "SRC-016", "title": "Consent Records and Receipts as per ISO/IEC TS 27560:2023 using DPV", "organization": "W3C Data Privacy Vocabularies and Controls Community Group", "url": "https://w3c-cg.github.io/dpv/guides/consent-27560", "version_or_date": "DPVCG guide, DPV 2.1 series, retrieved 23 August 2026", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T09:00:00Z", "relevance": "Field-level rendering of the ISO/IEC TS 27560 consent record: schema version, record identifier (UUID-4 recommended), data subject identifier, notice reference and language, purpose, personal data types and necessity, sensitivity flags, processing operations, sources, storage conditions, controllers, legal basis, recipients, withdrawal method, jurisdiction, rights, and consent event fields (timestamp, validity duration, expressing entity, event type, state, expression method)." }, { "id": "SRC-017", "title": "HL7 FHIR R5 Resource Consent", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/consent.html", "version_or_date": "FHIR R5 5.0.0, published 2023-03-26", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Computable privacy consent directive: identifier, status, grantor, grantee, manager, controller, period, decision permit/deny, nested provisions, purpose, data meaning, verification, source attachments and policyBasis including ODRL." }, { "id": "SRC-018", "title": "ISO/IEC 29184:2020 Information technology - Online privacy notices and consent", "organization": "ISO/IEC JTC 1/SC 27", "url": "https://www.iso.org/standard/70331.html", "version_or_date": "29184:2020 Edition 1, confirmed 2026", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Controls for notice content/structure and for obtaining consent that is fair, demonstrable, transparent, unambiguous and revocable. This mixin references notices; it does not implement notice UX." }, { "id": "SRC-019", "title": "Consent Records and Receipts as per ISO/IEC TS 27560:2023 using DPV", "organization": "W3C Data Privacy Vocabularies and Controls Community Group", "url": "https://w3id.org/dpv/guides/consent-27560", "version_or_date": "Final Community Group Report 15 February 2026", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Authoritative field mapping among ISO 27560, GDPR and DPV; consent lifecycle states; record versus receipt; documents the Kantara receipt-direction conflict." } ], "structure": { "bundles": [ { "id": "grant-instrument", "name": "Grant Instrument", "description": "The permission itself as a durable object: who permits, who may read, over which slice, for which purpose, under which conditions, and with which duties attached to the reader.", "rationale": "Every authoritative instrument examined separates the same components: ODRL splits a Rule into party functions, target, action, constraint and duty; HIPAA 164.508 enumerates description of information, authorised parties, purpose and expiration as core elements; FHIR Consent nests actor, action, purpose, dataPeriod and data inside provisions. Modelling these as one bundle keeps the instrument independent of the data it covers.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-011" ], "layers": [ { "id": "parties-and-authority", "name": "Parties and Authority", "description": "The grantor and the grantee, the capacity in which each acts, and the verification that the grantor was entitled to permit at all.", "source_refs": [ "SRC-001", "SRC-007", "SRC-009", "SRC-011" ], "findings": [ { "id": "grantor-authority-basis", "name": "Grantor identity and authority basis", "description": "Who asserts the right to permit reading, in what capacity (self, personal representative, guardian, delegate, institutional custodian), what evidence supports that capacity, and the outcome and time of verification against the ownership or delegation record. A grant issued without a verified basis is void rather than merely disputed.", "source_refs": [ "SRC-003", "SRC-004", "SRC-007", "SRC-009", "SRC-011" ], "questions": [ { "id": "q-grantor-identifier", "text": "Which authoritative identifier designates the grantor, and in which master system is it resolved?", "kind": "identity", "answer_data": [ "grantor identifier value", "issuing master system identifier", "identifier scheme or namespace", "resolution timestamp" ] }, { "id": "q-grantor-capacity", "text": "In what capacity does the grantor act — data subject, owner, personal representative, guardian, or delegate?", "kind": "authority", "answer_data": [ "capacity code from governed vocabulary", "reference to the delegation or guardianship record relied on", "scope limits of that capacity" ] }, { "id": "q-authority-evidence", "text": "What evidence documents the representative's authority, and when was it last verified?", "kind": "evidence", "answer_data": [ "evidence artefact reference", "verifier identity", "verification outcome", "verification timestamp with offset" ] }, { "id": "q-authority-lapse", "text": "What happens to an active grant if the authority basis lapses or is later found invalid?", "kind": "exception", "answer_data": [ "effect code (void ab initio, suspend, terminate forward)", "effective instant of the effect", "reason code", "notification obligation" ] } ], "data_elements": [ { "id": "grantor-id", "name": "Grantor identifier", "description": "Authoritative identifier of the party permitting the read, resolved in a named master system.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "grantor-capacity-code", "name": "Grantor capacity", "description": "Coded capacity in which the grantor acts, drawn from a governed vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-011" ] }, { "id": "authority-verification-outcome", "name": "Authority verification outcome", "description": "Result of checking the asserted capacity against the ownership or delegation record, with the time of the check.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-011" ] } ], "artifacts": [ { "id": "authority-verification-record", "name": "Authority verification record", "description": "The captured evidence and outcome of confirming that the grantor could lawfully permit the read, including any representative documentation relied on.", "media_or_form": [ "structured record object", "signed attestation", "scanned or attached representative documentation" ], "serial": true, "identity_strategy": "UUID or ULID assigned by the adopting Dimension, carrying the master ownership record identifier as a resolvable reference; one record per verification event.", "source_refs": [ "SRC-011", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "grantee-designation", "name": "Grantee designation and onward recipients", "description": "Who may read under the grant — a named party, a defined class or collection, or the bearer of a ticket — and which onward recipients or sub-processors, if any, are inside the grant and under what flow-down duties.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-006", "SRC-011" ], "questions": [ { "id": "q-grantee-kind", "text": "Is the grantee an individually named party, a party collection, or a bearer of a transferable ticket?", "kind": "classification", "answer_data": [ "grantee designation kind code", "grantee identifier or collection selector", "transferability flag" ] }, { "id": "q-onward-recipients", "text": "Which onward recipients or sub-processors are within the grant, and under which flow-down duties?", "kind": "relationship", "answer_data": [ "recipient identifiers or recipient category codes", "flow-down duty references", "permitted onward jurisdictions" ] }, { "id": "q-grantee-authn", "text": "How is the grantee authenticated at read time, and at what assurance level?", "kind": "security", "answer_data": [ "required authentication method", "minimum assurance level", "attribute source for the assurance claim" ] }, { "id": "q-subdelegation", "text": "May the grantee sub-delegate its read right, and what record must exist if it does?", "kind": "authority", "answer_data": [ "sub-delegation permitted flag", "required sub-delegation record type", "notification requirement to the grantor" ] } ], "data_elements": [ { "id": "grantee-ref", "name": "Grantee reference", "description": "Identifier or collection selector naming who may exercise the grant.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-011" ] }, { "id": "recipient-category", "name": "Recipient category", "description": "Coded category of recipient used where individual recipients cannot be enumerated in advance.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "assurance-level-min", "name": "Minimum authentication assurance", "description": "Lowest acceptable assurance level for the reader at exercise time.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Grantee designation is a set of references and coded categories carried inline on the instrument. No separate document is produced: where a named party needs supporting documentation, that documentation belongs to the identity or ownership sibling model, and where a ticket is issued the token is a projection governed by the decision surface, not an artefact of this finding." }, { "id": "party-functional-roles", "name": "Party functional roles", "description": "ODRL requires Agreement to name assigner and assignee; Offer requires assigner. FHIR names grantor (who grants rights), grantee (who must comply with the directive, including obligations), manager (lifecycle), controller (enforcer), and subject (who the consent is about). UMA distinguishes resource owner, requesting party, client, resource server and authorization server, and allows the requesting party to differ from the owner. Party collections may be refined (for example friends over age 18). FHIR comments that grantor/grantee are search conveniences and that fully computable consents list both as actors inside provisions. The Kantara Consent Receipt historically treats the PII principal as issuing a receipt to the controller, whereas ISO 27560 treats the organisation as issuing a receipt to the individual.", "source_refs": [ "SRC-001", "SRC-017", "SRC-019", "SRC-009" ], "questions": [ { "id": "party-functional-roles-q01", "text": "Who is the grantor, and which ownership, parental-responsibility or delegation record authorises them to grant?", "kind": "authority", "answer_data": [ "grantor_party_id", "capacity_code", "ownership_authority_ref" ] }, { "id": "party-functional-roles-q02", "text": "Which party or party collection is the grantee, and are members refined by attributes such as role or age?", "kind": "access", "answer_data": [ "grantee_party_id", "party_collection_refinement", "requesting_party_id" ] }, { "id": "party-functional-roles-q03", "text": "Is the data subject a different person from the grantor, as with a parent granting over a child's record?", "kind": "relationship", "answer_data": [ "subject_party_id", "grantor_party_id", "capacity_code" ] }, { "id": "party-functional-roles-q04", "text": "Which actor manages the instrument through its lifecycle and which actor evaluates reads against it?", "kind": "ownership", "answer_data": [ "manager_party_id", "enforcer_party_id" ] } ], "data_elements": [ { "id": "party-functional-roles-data01", "name": "grantor_party_id", "description": "ODRL assigner / FHIR grantor. Must resolve to an ownership or capacity record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017" ] }, { "id": "party-functional-roles-data02", "name": "grantee_party_id", "description": "ODRL assignee / FHIR grantee / UMA requesting party or client.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017", "SRC-009" ] }, { "id": "party-functional-roles-data03", "name": "subject_party_id", "description": "PII principal or FHIR subject when different from grantor.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-005" ] }, { "id": "party-functional-roles-data04", "name": "manager_party_id", "description": "FHIR manager; UMA authorization server operator is not automatically the manager.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-009" ] }, { "id": "party-functional-roles-data05", "name": "enforcer_party_id", "description": "FHIR controller; data holder that evaluates reads.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "party-functional-roles-data06", "name": "party_collection_refinement", "description": "ODRL PartyCollection.refinement.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "party-functional-roles-data07", "name": "ownership_authority_ref", "description": "Reference to ownership/delegation/guardianship record; not stored as title here.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-017" ] } ], "artifacts": [ { "id": "party-functional-roles-artifact01", "name": "Party roster", "description": "Resolved party identifiers, roles, collection membership and authority references for one instrument.", "media_or_form": [ "canonical-record" ], "serial": false, "identity_strategy": "Scoped to access_contract_id; each entry keyed by party IRI plus functional role.", "source_refs": [ "SRC-001", "SRC-017", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "scope-selection", "name": "Scope Selection", "description": "Which objects and which of their attributes the grant covers, how the covered set is designated and resolved, and how sensitivity changes what is required.", "source_refs": [ "SRC-007", "SRC-010", "SRC-011" ], "findings": [ { "id": "scope-clause-selection", "name": "Scope clause and selection mechanism", "description": "How the covered slice is designated — enumerated identifiers, coded categories, or an evaluable selector expression — whether the covered set is frozen at activation or re-evaluated at every read, and the specificity floor below which a clause is rejected as not identifying the information in a specific and meaningful way.", "source_refs": [ "SRC-001", "SRC-007", "SRC-010", "SRC-011" ], "questions": [ { "id": "q-selector-kind", "text": "How is the covered set designated: enumerated identifiers, category codes, or an evaluable selector expression?", "kind": "composition", "answer_data": [ "selector kind code", "selector value or expression", "expression language identifier" ] }, { "id": "q-resolution-mode", "text": "Is the covered set resolved as a snapshot at activation or re-evaluated live at each read?", "kind": "state", "answer_data": [ "resolution mode code", "snapshot reference if frozen", "re-evaluation trigger conditions" ] }, { "id": "q-data-period", "text": "Which creation or observation window of the covered objects falls inside the grant?", "kind": "temporal", "answer_data": [ "data period start", "data period end", "period semantics (creation, observation, or record time)" ] }, { "id": "q-specificity-floor", "text": "What is the specificity floor below which a scope clause must be rejected as too broad to be meaningful?", "kind": "constraint", "answer_data": [ "minimum required selector precision", "prohibited wildcard patterns", "validation rule identifier" ] } ], "data_elements": [ { "id": "scope-selector", "name": "Scope selector", "description": "The expression, identifier list or category set that determines which objects the clause covers.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-010" ] }, { "id": "projection-policy-ref", "name": "Projection policy reference", "description": "Identifier of the disclosure shape in which covered objects may leave; resolved in the sibling projection model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "scope-data-period", "name": "Covered data period", "description": "Time window of the covered data itself, distinct from the validity window of the grant.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "scope-clause-set", "name": "Scope clause set", "description": "The ordered set of clauses that partitions the grant into concrete, independently evaluable slices, each pointing at a projection policy.", "media_or_form": [ "structured clause list", "policy expression document", "tabular clause register" ], "serial": false, "identity_strategy": "Contract identifier plus clause ordinal, versioned with the contract; clauses are never renumbered across versions, superseded ordinals are retired.", "source_refs": [ "SRC-001", "SRC-007", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "data-category-sensitivity", "name": "Data category and sensitivity classification", "description": "Classification of the covered data by governed category and by sensitivity, because special or sensitive categories change the required form of the instrument, may demand explicit consent or a separate authorization, and may forbid combining the grant with others.", "source_refs": [ "SRC-003", "SRC-005", "SRC-006", "SRC-007", "SRC-011", "SRC-016" ], "questions": [ { "id": "q-data-categories", "text": "Which data categories are covered, expressed in which governed vocabulary and version?", "kind": "classification", "answer_data": [ "category codes", "vocabulary identifier", "vocabulary version" ] }, { "id": "q-special-category", "text": "Does the scope include special-category or sensitive data that requires explicit consent or a separate instrument?", "kind": "requirement", "answer_data": [ "sensitivity flag per category", "required instrument form code", "separate-instrument requirement flag" ] }, { "id": "q-carve-outs", "text": "Which categories are explicitly excluded by carve-out, and how is the exclusion enforced at read time?", "kind": "constraint", "answer_data": [ "excluded category codes", "enforcement point reference", "behaviour when exclusion cannot be applied" ] }, { "id": "q-security-labels", "text": "Which security labels or handling caveats travel with the covered data once disclosed?", "kind": "security", "answer_data": [ "security label codes", "label propagation rule", "handling caveat text" ] } ], "data_elements": [ { "id": "data-category-code", "name": "Data category code", "description": "Coded category of personal or non-personal data covered by a scope clause.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "sensitivity-flag", "name": "Sensitivity flag", "description": "Whether a covered category is special or sensitive under the governing regime.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-016" ] }, { "id": "security-label", "name": "Security label", "description": "Handling caveat that travels with disclosed data.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Classification is coded reference data resolved from a governed external vocabulary and carried inline on the scope clause; the authoritative artefact is the vocabulary itself, which is owned by a sibling classification model, not produced here." } ] }, { "id": "purpose-and-action", "name": "Purpose and Permitted Action", "description": "The declared use the grant is limited to and the operations it permits, which together bound what a lawful read may become.", "source_refs": [ "SRC-002", "SRC-003", "SRC-013" ], "findings": [ { "id": "purpose-specification", "name": "Purpose specification and limitation", "description": "The declared purpose in human-readable form and in a governed purpose taxonomy, the granularity required when several purposes are bundled, and the factors by which a proposed further use is judged compatible or is refused and sent back for a new grant.", "source_refs": [ "SRC-003", "SRC-004", "SRC-006", "SRC-013", "SRC-002" ], "questions": [ { "id": "q-purpose-terms", "text": "What is the declared purpose, and which coded purpose terms express it?", "kind": "definition", "answer_data": [ "purpose text", "coded purpose terms", "taxonomy identifier and version" ] }, { "id": "q-purpose-compatibility", "text": "Is a proposed use inside the declared purpose, or does it require a new grant?", "kind": "decision", "answer_data": [ "compatibility assessment factors applied", "assessment outcome", "assessor identity and time" ] }, { "id": "q-purpose-granularity", "text": "How granular must purposes be when several are offered in one instrument?", "kind": "requirement", "answer_data": [ "separability rule", "per-purpose acceptance record", "bundling prohibition flag" ] }, { "id": "q-purpose-drift", "text": "How is a later narrowing or widening of the declared purpose detected and handled?", "kind": "lifecycle", "answer_data": [ "purpose change event", "required re-consent flag", "effective instant of the change" ] } ], "data_elements": [ { "id": "purpose-code", "name": "Purpose code", "description": "Coded term from a governed purpose taxonomy limiting the use of the disclosed data.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-013" ] }, { "id": "purpose-text", "name": "Purpose statement text", "description": "Human-readable description of the declared purpose as presented to the grantor.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-011" ] }, { "id": "purpose-acceptance", "name": "Per-purpose acceptance", "description": "Whether the grantor accepted each purpose separately where granularity is required.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "purpose-statement", "name": "Purpose statement", "description": "The bounded declaration of use, pairing the wording shown to the grantor with the coded terms that machines evaluate, plus any compatibility notes.", "media_or_form": [ "structured statement object", "coded term set", "narrative text block" ], "serial": false, "identity_strategy": "Governed purpose taxonomy IRI where a coded term exists; otherwise contract identifier plus purpose ordinal, versioned with the contract.", "source_refs": [ "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "permitted-action-read-semantics", "name": "Permitted action and read semantics", "description": "Which operations the grant permits and which it prohibits, and what a permitted read actually includes — retrieval only, or also caching, indexing, derivation, aggregation and re-disclosure. Ambiguity here is the most common cause of a grant being exceeded without anyone noticing.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-008", "SRC-010" ], "questions": [ { "id": "q-action-terms", "text": "Which action terms are permitted and which are explicitly prohibited under this instrument?", "kind": "classification", "answer_data": [ "permitted action codes", "prohibited action codes", "action vocabulary identifier" ] }, { "id": "q-read-includes", "text": "Does a permitted read include caching, indexing, derivation or aggregation of the disclosed data?", "kind": "definition", "answer_data": [ "derived-use permission flags per operation", "retention limit for cached copies", "attribution or provenance requirement on derivatives" ] }, { "id": "q-exercise-unit", "text": "Is one decision valid for a single read, a session, or a standing entitlement?", "kind": "state", "answer_data": [ "exercise unit code", "maximum reliance duration", "re-evaluation trigger" ] }, { "id": "q-out-of-scope-actions", "text": "Which actions beyond read fall outside this mixin and must be modelled elsewhere?", "kind": "interoperability", "answer_data": [ "excluded action codes", "target model reference for each excluded action" ] } ], "data_elements": [ { "id": "permitted-action", "name": "Permitted action", "description": "Coded operation the grantee may perform on the covered data.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "prohibited-action", "name": "Prohibited action", "description": "Coded operation expressly forbidden even if otherwise implied by the permitted action.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "exercise-unit", "name": "Exercise unit", "description": "Granularity at which a coverage decision is valid: per read, per session, or standing.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Action terms are coded references into a governed action vocabulary carried inline on the rule; producing a separate artefact would duplicate the vocabulary, which is external reference data maintained by the standards bodies aligned in the interoperability bundle." } ] }, { "id": "conditions-and-obligations", "name": "Conditions and Obligations", "description": "The machine-evaluable limits on the permission and the duties the reader accepts in exchange for it.", "source_refs": [ "SRC-001", "SRC-002", "SRC-013" ], "findings": [ { "id": "constraints-validity-window", "name": "Constraints and validity window", "description": "Every bound that a decision engine must evaluate: entry into force, expiry by date or by event, frequency and volume caps, spatial and jurisdictional limits, and environment conditions — together with the behaviour when a constraint attribute is simply unavailable.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-008", "SRC-011" ], "questions": [ { "id": "q-validity-window", "text": "When does the grant enter into force and when does it end — a fixed instant, a defined event, or never?", "kind": "temporal", "answer_data": [ "valid-from timestamp with offset", "valid-until timestamp with offset", "expiry event definition", "no-expiry flag with justification" ] }, { "id": "q-quantitative-limits", "text": "Which quantitative limits apply, such as reads per period, total count or data volume?", "kind": "measurement", "answer_data": [ "limit operand", "limit operator", "limit value and unit", "counter reset period" ] }, { "id": "q-spatial-limits", "text": "Which spatial or jurisdictional constraints restrict where the read may occur or where disclosed data may land?", "kind": "spatial", "answer_data": [ "permitted territory codes", "prohibited territory codes", "transfer safeguard reference" ] }, { "id": "q-unevaluable-constraint", "text": "What outcome applies when a constraint cannot be evaluated because an attribute is missing?", "kind": "exception", "answer_data": [ "default outcome code", "attribute source fallback", "alerting requirement" ] } ], "data_elements": [ { "id": "valid-from", "name": "Valid from", "description": "Instant at which the grant enters into force, in RFC 3339 with explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "valid-until", "name": "Valid until", "description": "Instant at which the grant lapses absent renewal, in RFC 3339 with explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "expiry-event", "name": "Expiry event", "description": "Defined event whose occurrence ends the grant where no fixed date is used.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "read-count-limit", "name": "Read count limit", "description": "Maximum number of exercises permitted within a stated period.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "constraint-expression-set", "name": "Constraint expression set", "description": "The machine-evaluable expressions attached to a rule or clause, in a declared expression language, that a decision point must satisfy before permitting a read.", "media_or_form": [ "policy constraint expression", "logical constraint tree", "rule engine ruleset" ], "serial": false, "identity_strategy": "Contract identifier plus clause ordinal plus constraint ordinal, with the expression language identifier and version recorded alongside.", "source_refs": [ "SRC-001", "SRC-002", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "obligations-and-duties", "name": "Obligations and duties on the grantee", "description": "Duties the reader accepts as the price of the grant — no onward sharing, deletion or return at the end, ethics approval, publication, attribution, collaboration — classified by whether they are pre-conditions, continuing duties or post-termination survivals, with the evidence needed to consider each discharged.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013", "SRC-014" ], "questions": [ { "id": "q-duty-timing", "text": "Which duties attach to the grantee, and is each a pre-condition, a continuing duty, or a post-termination survival?", "kind": "requirement", "answer_data": [ "duty codes", "duty timing class", "duty deadline or duration" ] }, { "id": "q-duty-consequence", "text": "What consequence applies if a duty is not discharged by its deadline?", "kind": "exception", "answer_data": [ "consequence code", "automatic suspension flag", "escalation target in the enforcement model" ] }, { "id": "q-duty-evidence", "text": "What evidence is required before a duty is treated as discharged?", "kind": "evidence", "answer_data": [ "required evidence type", "acceptable evidence issuer", "evidence retention period" ] }, { "id": "q-duty-survival", "text": "Which duties survive revocation or expiry of the grant, and for how long?", "kind": "lifecycle", "answer_data": [ "surviving duty codes", "survival duration", "termination condition for the survival" ] } ], "data_elements": [ { "id": "duty-code", "name": "Duty code", "description": "Coded obligation accepted by the grantee, drawn from a governed duty vocabulary.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-013" ] }, { "id": "duty-deadline", "name": "Duty deadline", "description": "Instant or duration by which the duty must be discharged.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "duty-status", "name": "Duty status", "description": "Current discharge state of a duty: pending, discharged, breached or waived.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] } ], "artifacts": [ { "id": "obligation-discharge-evidence", "name": "Obligation discharge evidence", "description": "The attestation, receipt or log excerpt submitted to show that a specific duty, such as end-of-grant erasure or return of results, was fulfilled.", "media_or_form": [ "signed attestation", "deletion certificate", "log excerpt", "publication reference" ], "serial": true, "identity_strategy": "Duty identifier plus monotonic discharge sequence number, bound to the contract version in force when the duty arose.", "source_refs": [ "SRC-001", "SRC-013", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "consent-act", "name": "Consent Act and Evidence", "description": "Where the grant rests on consent, the human act behind the instrument: how it was expressed, in what context, whether it meets the validity test, and what durable, portable evidence exists.", "rationale": "Consent is legally distinct from the permission it produces: GDPR Art 4(11) defines the act, Art 7(1) requires the controller to be able to demonstrate it, and ISO/IEC TS 27560 with the DPVCG mapping defines a separate record structure for it with its own identifier and event history. HIPAA 164.508 shows the same separation for signed authorizations retained under 164.530(j).", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-011", "SRC-016" ], "layers": [ { "id": "consent-expression", "name": "Consent Expression and Validity", "description": "The act itself, its capture context, and whether it satisfies the normative test for valid consent in the governing regime.", "source_refs": [ "SRC-003", "SRC-004", "SRC-016" ], "findings": [ { "id": "consent-validity-elements", "name": "Consent validity elements", "description": "Whether the recorded act was freely given, specific, informed and unambiguous, whether explicit consent was required and how the heightened standard was met, and — critically — which of these elements is actually evidenced in the record rather than merely asserted by the capturing system.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-006", "SRC-016" ], "questions": [ { "id": "q-affirmative-act", "text": "Which affirmative act constituted the indication, and was any pre-ticked box, silence or inactivity relied on?", "kind": "validation", "answer_data": [ "indication mechanism code", "pre-ticked or inactivity reliance flag", "interface element identifier" ] }, { "id": "q-conditioning", "text": "Was the service or contract made conditional on consent that was not necessary to perform it?", "kind": "constraint", "answer_data": [ "conditioning flag", "necessity justification", "alternative offered to the grantor" ] }, { "id": "q-explicit-consent", "text": "Was explicit consent required, and by what mechanism was the heightened standard met?", "kind": "requirement", "answer_data": [ "explicit consent required flag", "trigger (special category, transfer, automated decision)", "mechanism used" ] }, { "id": "q-asserted-vs-evidenced", "text": "Which validity elements are evidenced in the record and which are only asserted by the capturing system?", "kind": "evidence", "answer_data": [ "per-element evidence status", "evidence artefact reference per element", "gap statement" ] } ], "data_elements": [ { "id": "consent-type", "name": "Consent type", "description": "Whether the act was express, explicit or inferred, using a governed vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "indication-mechanism", "name": "Indication mechanism", "description": "How the affirmative act was performed, such as a signature, a checkbox, an in-person statement or a spoken confirmation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "validity-element-status", "name": "Validity element status", "description": "Per-element record of whether freely given, specific, informed and unambiguous are evidenced, asserted or unmet.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "consent-validity-assessment", "name": "Consent validity assessment", "description": "A structured assessment recording, element by element, why the captured act is treated as valid, who made that determination and against which regime.", "media_or_form": [ "structured assessment object", "reviewed assessment note" ], "serial": false, "identity_strategy": "Consent record identifier plus assessment version; superseded assessments are retained, never overwritten.", "source_refs": [ "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "consent-capture-context", "name": "Capture context and notice reference", "description": "The circumstances that make consent auditable: the channel and interface used, the exact notice or wording version shown, the language, the jurisdiction at capture, and the separation between the time the act occurred and the time the record was written.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-015", "SRC-016" ], "questions": [ { "id": "q-capture-channel", "text": "Through which channel and interface was the act captured, and what exact wording version was displayed?", "kind": "provenance", "answer_data": [ "collection method code", "interface or endpoint identifier", "notice version identifier" ] }, { "id": "q-capture-language", "text": "Which language and which jurisdiction applied at the moment of capture?", "kind": "spatial", "answer_data": [ "language tag", "jurisdiction identifier", "applicable regime reference" ] }, { "id": "q-act-vs-record-time", "text": "What was the event time of the act as against the time the record was ingested?", "kind": "temporal", "answer_data": [ "act timestamp with explicit offset", "record ingestion timestamp with explicit offset", "clock source and skew tolerance" ] }, { "id": "q-notice-retrievability", "text": "Is the referenced notice version immutably retrievable for the life of the record?", "kind": "quality", "answer_data": [ "notice snapshot reference", "immutability mechanism", "retrieval guarantee period" ] } ], "data_elements": [ { "id": "collection-method", "name": "Collection method", "description": "Coded channel and mechanism through which the act was captured.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-016" ] }, { "id": "notice-version-ref", "name": "Notice version reference", "description": "Identifier of the exact notice or policy version presented at capture.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-016" ] }, { "id": "consent-act-time", "name": "Consent act time", "description": "Instant at which the grantor performed the affirmative act, in RFC 3339 with explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-015" ] }, { "id": "consent-record-time", "name": "Consent record time", "description": "Instant at which the act was written to the record store, recorded separately from the act time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "notice-snapshot", "name": "Notice snapshot", "description": "An immutable rendering of the notice, wording and interface state actually presented to the grantor at the moment of capture, held as evidence independent of the live notice.", "media_or_form": [ "rendered document", "markup capture", "screen capture", "plain text transcript" ], "serial": true, "identity_strategy": "Notice IRI plus version, with a content digest; one snapshot per distinct presented version, never mutated after capture.", "source_refs": [ "SRC-004", "SRC-005", "SRC-015" ] } ], "inline_only_rationale": null } ] }, { "id": "consent-evidence", "name": "Consent Evidence and Receipt", "description": "The durable record that supports demonstrability and the portable copy given back to the grantor.", "source_refs": [ "SRC-005", "SRC-012", "SRC-014", "SRC-015" ], "findings": [ { "id": "consent-record-and-proof", "name": "Consent record and proof of act", "description": "The structured, versioned record that lets an accountable party demonstrate the act, the schema it conforms to, the proof binding the record to the grantor, and the minimum that must survive if the underlying data is later deleted.", "source_refs": [ "SRC-003", "SRC-005", "SRC-011", "SRC-012", "SRC-016" ], "questions": [ { "id": "q-record-schema", "text": "Which record structure and schema version is used to demonstrate the act?", "kind": "interoperability", "answer_data": [ "schema identifier", "schema version", "conformance statement and its evidence" ] }, { "id": "q-record-proof", "text": "What proof binds the record to the grantor's act, and who can verify it independently?", "kind": "evidence", "answer_data": [ "proof type", "signing or witnessing party", "independent verification procedure" ] }, { "id": "q-record-integrity", "text": "Is the record tamper-evident, and how is its integrity re-checked over time?", "kind": "quality", "answer_data": [ "digest algorithm and value", "canonicalisation rule applied", "re-verification schedule" ] }, { "id": "q-minimum-survivor", "text": "What minimum record must survive after the covered data itself is deleted?", "kind": "retention", "answer_data": [ "surviving field set", "redaction rule", "survival duration and basis" ] } ], "data_elements": [ { "id": "consent-record-id", "name": "Consent record identifier", "description": "Stable identifier of the consent record, assigned as a UUID or ULID by the adopting Dimension where no master-system identifier exists.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-016" ] }, { "id": "consent-schema-version", "name": "Consent record schema version", "description": "Declared structure version the record conforms to, enabling safe cross-system interpretation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "consent-proof", "name": "Consent proof", "description": "Cryptographic or procedural proof binding the record to the act and the acting party.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] } ], "artifacts": [ { "id": "consent-record", "name": "Consent record", "description": "The authoritative, structured record of a consent event including the notice reference, processing details, event type, event state and expressing entity.", "media_or_form": [ "structured record object", "linked-data graph", "signed document" ], "serial": true, "identity_strategy": "UUID or ULID assigned by the adopting Dimension, one per consent event, linked to the contract identifier and to the prior event in the chain; timestamps are never used as identifiers.", "source_refs": [ "SRC-005", "SRC-016", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "receipt-and-portability", "name": "Receipt issuance and portability", "description": "The grantor-facing copy of what was agreed: what it must contain to be actionable, how it is delivered and re-obtained, whether a third party can verify it and check its current status, and whether it is machine-readable enough to drive withdrawal in another system.", "source_refs": [ "SRC-005", "SRC-012", "SRC-014", "SRC-015", "SRC-016" ], "questions": [ { "id": "q-receipt-content", "text": "What must the receipt contain for the grantor to understand and act on what they agreed?", "kind": "definition", "answer_data": [ "required receipt field set", "controller and contact details", "withdrawal method description" ] }, { "id": "q-receipt-delivery", "text": "Through which channel is the receipt delivered, and how is it re-obtained later?", "kind": "process", "answer_data": [ "delivery channel", "re-issue endpoint or procedure", "delivery confirmation record" ] }, { "id": "q-receipt-verification", "text": "Can a third party verify the receipt without contacting the issuer, and how is its current status checked?", "kind": "validation", "answer_data": [ "verification method", "status check mechanism", "status values and their meaning" ] }, { "id": "q-receipt-machine-readable", "text": "Is the receipt machine-readable enough to drive withdrawal in a system other than the issuer's?", "kind": "interoperability", "answer_data": [ "machine-readable format identifier", "withdrawal endpoint carried in the receipt", "cross-system identifier binding" ] } ], "data_elements": [ { "id": "receipt-id", "name": "Receipt identifier", "description": "Identifier of the issued receipt, distinct from the consent record identifier it attests.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-005" ] }, { "id": "receipt-status", "name": "Receipt status", "description": "Current verifiable status of the receipt, supporting revocation and suspension checks by a verifier.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "withdrawal-method", "name": "Withdrawal method", "description": "The effective, clearly communicated technical means by which the grantor may withdraw.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-016" ] } ], "artifacts": [ { "id": "consent-receipt", "name": "Consent receipt", "description": "The durable, portable copy of what the grantor agreed to, issued back to them and independently presentable to third parties.", "media_or_form": [ "structured receipt object", "verifiable credential", "human-readable rendered document" ], "serial": true, "identity_strategy": "Receipt identifier as a governed URI where the Dimension operates a namespace, otherwise a UUID or ULID, bound to the consent record identifier and the contract version it attests.", "source_refs": [ "SRC-015", "SRC-012", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "lifecycle", "name": "Lifecycle and Change", "description": "How a grant is born, changes, is suspended, ends, and how its ending reaches everyone who relied on it.", "rationale": "Every source that models permission as an object also models its states: DPV enumerates eight consent statuses, FHIR Consent carries a status element, VC 2.0 provides credentialStatus for revocation and suspension, GDPR Art 7(3) fixes the non-retroactive effect of withdrawal, and Art 19 imposes downstream notification. A permission without an explicit state machine cannot be safely relied on.", "source_refs": [ "SRC-003", "SRC-006", "SRC-007", "SRC-012" ], "layers": [ { "id": "states-and-transitions", "name": "States and Transitions", "description": "The enumerated states of an instrument, the legal transitions between them, and the clocks that govern them.", "source_refs": [ "SRC-006", "SRC-007", "SRC-012" ], "findings": [ { "id": "contract-state-model", "name": "Instrument state model", "description": "The state set and the legal transitions, so that any reader can determine deterministically whether the grant is live, including the treatment of proposed-but-unaccepted instruments, suspension short of termination, and disagreement between the record store and an already-issued token.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-012" ], "questions": [ { "id": "q-state-set", "text": "What is the enumerated state set, and which transitions between states are legal?", "kind": "state", "answer_data": [ "state codes", "permitted transition pairs", "transition trigger per pair" ] }, { "id": "q-authoritative-state", "text": "Which state is authoritative when the record store and a previously issued token disagree?", "kind": "decision", "answer_data": [ "precedence rule", "maximum token reliance window", "reconciliation procedure" ] }, { "id": "q-suspension", "text": "Can an instrument be suspended without being terminated, and what does suspension permit?", "kind": "lifecycle", "answer_data": [ "suspension supported flag", "permitted operations while suspended", "resumption conditions" ] }, { "id": "q-proposed-vs-active", "text": "How is a proposed or requested instrument distinguished from an accepted and active one?", "kind": "classification", "answer_data": [ "instrument kind code (request, offer, agreement)", "acceptance event reference", "activation precondition list" ] } ], "data_elements": [ { "id": "instrument-state", "name": "Instrument state", "description": "Current lifecycle state of the grant.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "instrument-kind", "name": "Instrument kind", "description": "Whether the object is a request, an offer, or a concluded agreement.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "state-changed-at", "name": "State change time", "description": "Instant of the most recent state transition, in RFC 3339 with explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "state-transition-table", "name": "State transition table", "description": "The governed matrix of states, legal transitions, triggers and required preconditions that implementations must enforce.", "media_or_form": [ "transition matrix", "state machine definition", "tabular register" ], "serial": false, "identity_strategy": "Model-scoped stable identifier plus semantic version; each published version is immutable and superseded versions remain resolvable.", "source_refs": [ "SRC-006", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "temporal-semantics", "name": "Temporal semantics of the instrument", "description": "The several distinct times a grant carries and which one governs which question: the act time, the record time, entry into force, lapse, the decision time, and the correction time. Getting the wrong clock produces a decision that is defensible in code and indefensible in fact.", "source_refs": [ "SRC-003", "SRC-007", "SRC-012", "SRC-016" ], "questions": [ { "id": "q-mandatory-times", "text": "Which timestamps are mandatory on every instrument and every consent event?", "kind": "temporal", "answer_data": [ "mandatory timestamp field list", "format rule", "offset requirement" ] }, { "id": "q-missing-offset", "text": "Is a time without an explicit offset ever acceptable, and what is the fallback if one is received?", "kind": "constraint", "answer_data": [ "acceptance rule", "fallback offset assumption", "quality flag raised" ] }, { "id": "q-retroactive-correction", "text": "How is a correction to a recorded time captured without rewriting history?", "kind": "provenance", "answer_data": [ "correction event record", "superseded value", "corrector identity and time" ] }, { "id": "q-straddling-read", "text": "Which time governs a read that begins before expiry and completes after it?", "kind": "exception", "answer_data": [ "governing instant rule", "in-flight read handling", "maximum completion grace" ] } ], "data_elements": [ { "id": "decision-time", "name": "Decision time", "description": "Instant at which a coverage decision was rendered, distinct from the read it authorises.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "effective-instant", "name": "Effective instant", "description": "Instant from which a state change takes legal effect, which may differ from when it was recorded.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "validity-duration", "name": "Validity duration", "description": "Declared duration of the consent or grant where expressed as a period rather than an end instant.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "These are scalar fields carried by the instrument, the consent record and the decision response, all of which are artefacts declared in other findings. Producing a separate temporal artefact would create a second, competing source of truth for the same instants." } ] }, { "id": "amendment-and-supersession", "name": "Amendment and Supersession", "description": "How a live instrument is narrowed, widened or renewed, and which changes require a fresh act of consent.", "source_refs": [ "SRC-001", "SRC-004", "SRC-011" ], "findings": [ { "id": "amendment-versioning-reconsent", "name": "Amendment, versioning and re-consent triggers", "description": "Which changes may be applied to a live instrument in place, which force a new consent act, how versions are identified and linked to their predecessors, from which instant a superseding version governs, and whether the regime imposes a refresh interval after which consent must be renewed.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-011" ], "questions": [ { "id": "q-inplace-vs-reconsent", "text": "Which changes may be applied in place and which require a new consent act?", "kind": "decision", "answer_data": [ "change class codes", "re-consent trigger rule per class", "approver of the classification" ] }, { "id": "q-version-identity", "text": "How are versions identified, ordered, and linked to the version they supersede?", "kind": "identity", "answer_data": [ "version identifier scheme", "predecessor reference", "ordering rule" ] }, { "id": "q-supersession-instant", "text": "From which instant does a superseding version govern, and what governs reads already in flight?", "kind": "temporal", "answer_data": [ "supersession effective instant", "in-flight read rule", "overlap handling" ] }, { "id": "q-refresh-interval", "text": "Is there an interval after which the instrument must be refreshed or re-confirmed?", "kind": "lifecycle", "answer_data": [ "refresh interval", "basis for the interval", "behaviour on lapse of the interval" ] } ], "data_elements": [ { "id": "contract-version", "name": "Contract version", "description": "Ordered version identifier of the instrument, incremented on every substantive change.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "supersedes-ref", "name": "Supersedes reference", "description": "Reference to the version this one replaces, forming an unbroken chain.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "reconsent-required", "name": "Re-consent required flag", "description": "Whether the change class obliges capture of a fresh consent act before the new version can activate.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-011" ] } ], "artifacts": [ { "id": "amendment-record", "name": "Amendment record", "description": "The structured record of one change to a live instrument: what changed, on whose authority, with which effect on scope, and whether a fresh consent act was required and obtained.", "media_or_form": [ "structured change record", "difference set", "countersigned amendment document" ], "serial": true, "identity_strategy": "Contract identifier plus new version identifier; amendment records are append-only and each names its predecessor version.", "source_refs": [ "SRC-001", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "termination-and-propagation", "name": "Termination and Propagation", "description": "Ending a grant early and making that ending real for everyone downstream.", "source_refs": [ "SRC-003", "SRC-011", "SRC-014" ], "findings": [ { "id": "revocation-and-withdrawal", "name": "Revocation, withdrawal and their effect", "description": "Who may end the grant early, through which channels it must be at least as easy as granting, from which instant termination bites, what it does not undo — prior lawful reads remain lawful and a reliance exception may apply — and what confirmation the grantor receives.", "source_refs": [ "SRC-003", "SRC-004", "SRC-006", "SRC-011", "SRC-014" ], "questions": [ { "id": "q-who-may-revoke", "text": "Who may issue a withdrawal or revocation, and through which channels must it be possible?", "kind": "authority", "answer_data": [ "authorised issuer roles", "required channels", "effort-parity evidence against the granting channel" ] }, { "id": "q-termination-instant", "text": "From which instant does termination take effect, and are prior reads thereby invalidated?", "kind": "temporal", "answer_data": [ "effective instant", "retroactivity rule", "status of reads already performed" ] }, { "id": "q-post-withdrawal-processing", "text": "Which processing may lawfully continue after withdrawal, and on what stated basis?", "kind": "exception", "answer_data": [ "continuing activity list", "legal or reliance basis per activity", "duration of continuation" ] }, { "id": "q-withdrawal-confirmation", "text": "What confirmation is returned to the grantor that the withdrawal took effect?", "kind": "evidence", "answer_data": [ "confirmation artefact reference", "confirmation delivery time", "downstream propagation status at time of confirmation" ] } ], "data_elements": [ { "id": "termination-reason", "name": "Termination reason", "description": "Coded reason for early termination, distinguishing grantor withdrawal, grantor-side revocation, authority failure and administrative invalidation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-003" ] }, { "id": "termination-effective-at", "name": "Termination effective instant", "description": "Instant from which the grant no longer covers any read, in RFC 3339 with explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-011" ] }, { "id": "reliance-exception", "name": "Reliance exception", "description": "Recorded basis on which some processing lawfully continues despite termination.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-003" ] } ], "artifacts": [ { "id": "revocation-notice", "name": "Revocation or withdrawal notice", "description": "The signed act that ends the grant, naming its issuer, reason, effective instant and the contract version terminated.", "media_or_form": [ "signed notice object", "written instrument", "structured event message" ], "serial": true, "identity_strategy": "UUID or ULID assigned by the adopting Dimension, carrying the contract identifier and the terminated version; one notice per termination act.", "source_refs": [ "SRC-003", "SRC-011", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "propagation-and-erasure", "name": "Downstream propagation and erasure confirmation", "description": "Making termination effective beyond the first holder: identifying every recipient that received data under the grant, notifying them within a deadline, collecting cutoff and deletion evidence, handling the case where notification is impossible or disproportionate, and deciding what happens to irreversible derivatives.", "source_refs": [ "SRC-001", "SRC-003", "SRC-013", "SRC-014" ], "questions": [ { "id": "q-who-to-notify", "text": "Which recipients must be notified of termination, and within what deadline?", "kind": "process", "answer_data": [ "recipient list or category list", "notification deadline", "channel per recipient" ] }, { "id": "q-cutoff-proof", "text": "What counts as acceptable proof that a recipient stopped reading and deleted its copies?", "kind": "evidence", "answer_data": [ "acceptable proof types", "proof issuer requirements", "verification step" ] }, { "id": "q-notification-impossible", "text": "What is done when notification is impossible or would involve disproportionate effort?", "kind": "exception", "answer_data": [ "impossibility justification record", "alternative measure taken", "grantor-facing disclosure of the gap" ] }, { "id": "q-derivatives", "text": "How are irreversible derivatives such as trained models, aggregates and publications handled?", "kind": "constraint", "answer_data": [ "derivative class", "permitted continuation basis", "mitigation or attribution requirement" ] } ], "data_elements": [ { "id": "notified-recipient", "name": "Notified recipient", "description": "A recipient that received data under the grant and was notified of its termination.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "cutoff-acknowledgement", "name": "Cutoff acknowledgement", "description": "A recipient's confirmation that reads ceased and copies were deleted or returned, with its time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "propagation-status", "name": "Propagation status", "description": "Aggregate state of the propagation effort: pending, partially acknowledged, complete, or blocked.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "propagation-ledger", "name": "Propagation ledger", "description": "The record of every recipient notified of a termination, the notification time, the acknowledgement received and any unresolved gap.", "media_or_form": [ "append-only ledger", "tabular register", "structured event stream" ], "serial": true, "identity_strategy": "Termination event identifier plus recipient identifier as a composite key; entries are append-only with corrections recorded as new entries.", "source_refs": [ "SRC-003", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "entitlement-cutoff", "name": "Entitlement tokens and cutoff", "description": "UMA issues an RPT unique to requesting party, client, authorization server, resource server and resource owner; permissions on the token are opaque to the client. Refresh MUST NOT re-run authorization assessment. RFC 7009 revocation, with UMA token type hint pct, cuts tokens. FHIR expects signatures and ceremony stages in Provenance, DocumentReference or Contract attachments rather than in Consent itself. After withdrawal or expiry, every holder of data under the grant must be notified and must confirm cutoff; ISO 27560 does not define that protocol, so this mixin records propagation status as an operating concern and leaves transport to implementations. Partial propagation is a first-class state, not a success. Cached validity tokens MUST expire no later than the grant window and SHOULD be revoked when the instrument is withdrawn.", "source_refs": [ "SRC-017", "SRC-005", "SRC-009" ], "questions": [ { "id": "entitlement-cutoff-q01", "text": "Is there a current entitlement token, of which kind, expiring when, and is it unique to this requesting party and client?", "kind": "security", "answer_data": [ "entitlement_token_id", "token_kind", "token_expires_at" ] }, { "id": "entitlement-cutoff-q02", "text": "Which parties currently hold copies or caches under this grant, and which have confirmed cutoff?", "kind": "process", "answer_data": [ "holder_party_ids", "propagation_status", "cutoff_confirmed_time" ] }, { "id": "entitlement-cutoff-q03", "text": "Were RPTs, refresh tokens and persisted-claims tokens revoked, at what time, and did refresh continue to mint access without re-assessment?", "kind": "security", "answer_data": [ "token_revoked_time", "token_kind" ] } ], "data_elements": [ { "id": "entitlement-cutoff-data01", "name": "entitlement_token_id", "description": "RPT or Dimension validity token; not the contract id.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "entitlement-cutoff-data02", "name": "token_kind", "description": "uma-rpt | refresh | pct | validity-token.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "entitlement-cutoff-data03", "name": "token_expires_at", "description": "Must not exceed grant validity_end.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "entitlement-cutoff-data04", "name": "holder_party_ids", "description": "Every known holder that must receive cutoff.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003", "SRC-005" ] }, { "id": "entitlement-cutoff-data05", "name": "propagation_status", "description": "not-required | pending | confirmed | partial | failed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "entitlement-cutoff-data06", "name": "cutoff_confirmed_time", "description": "When a holder acknowledged no further reads.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-005" ] }, { "id": "entitlement-cutoff-data07", "name": "token_revoked_time", "description": "RFC 7009 or local revoke event time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "entitlement-cutoff-artifact01", "name": "Revocation propagation ledger", "description": "Per-holder cutoff acknowledgements and token revocation times for one termination event.", "media_or_form": [ "event-artefact" ], "serial": true, "identity_strategy": "One ledger per termination_event_id, with entries keyed by holder party IRI and acknowledgement time.", "source_refs": [ "SRC-003", "SRC-005", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "decision-surface", "name": "Decision and Verification Surface", "description": "The minimal, privacy-preserving interface by which a data holder asks whether a specific read is covered, and how competing instruments are combined into one answer.", "rationale": "XACML separates the decision point from the enforcement point and fixes a four-value outcome vocabulary with attached obligations; UMA 2.0 shows the resource owner setting policy in advance and the authorization server answering at runtime; RFC 9396 requires the granted authorization details to be returned so the enforcing party can act on them. The instrument is useless unless this surface is specified independently of the instrument's content.", "source_refs": [ "SRC-008", "SRC-009", "SRC-010" ], "layers": [ { "id": "coverage-decision", "name": "Coverage Decision", "description": "The request, the outcome vocabulary, the returned obligations and the handling of unevaluable cases.", "source_refs": [ "SRC-008", "SRC-009", "SRC-010" ], "findings": [ { "id": "coverage-decision-exchange", "name": "Coverage decision request and response", "description": "What a holder must supply for a decision to be evaluable, what may be returned beyond the bare outcome, and how long a decision may be relied on — deliberately structured so the asking party learns nothing about parties, purpose or terms it does not need.", "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-010" ], "questions": [ { "id": "q-decision-inputs", "text": "Which attributes must the requester supply before a decision can be evaluated at all?", "kind": "process", "answer_data": [ "required attribute list", "attribute source or issuer", "behaviour on missing attribute" ] }, { "id": "q-decision-values", "text": "Which decision values may be returned, and what must the enforcing party do for each?", "kind": "decision", "answer_data": [ "outcome vocabulary", "required enforcement behaviour per outcome", "logging obligation per outcome" ] }, { "id": "q-decision-payload", "text": "What may be returned alongside the outcome — obligations, scope fingerprint, expiry — without disclosing contract content?", "kind": "privacy", "answer_data": [ "permitted response field set", "scope fingerprint construction rule", "fields explicitly withheld" ] }, { "id": "q-decision-reliance", "text": "How long may a decision be cached and relied upon before re-evaluation?", "kind": "temporal", "answer_data": [ "maximum reliance duration", "invalidation triggers", "cache key composition" ] } ], "data_elements": [ { "id": "decision-outcome", "name": "Decision outcome", "description": "The rendered outcome of a coverage evaluation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-007" ] }, { "id": "returned-obligations", "name": "Returned obligations", "description": "Duties the enforcing party must discharge as a condition of acting on the outcome.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "scope-fingerprint", "name": "Scope fingerprint", "description": "A non-reversible digest that lets a holder confirm the decision applied to the intended slice without disclosing the clause.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "decision-correlation-id", "name": "Decision correlation identifier", "description": "Identifier linking the decision to the audit record of the exercise in the sibling audit model.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-014" ] } ], "artifacts": [ { "id": "decision-response", "name": "Decision response", "description": "The structured answer returned to an enforcing party: outcome, obligations, validity horizon and correlation identifier, and nothing else.", "media_or_form": [ "structured response object", "token claim set", "introspection response" ], "serial": true, "identity_strategy": "Decision correlation identifier assigned per evaluation, bound to the contract identifier and version evaluated; never reused.", "source_refs": [ "SRC-008", "SRC-010", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "fail-closed-handling", "name": "Unevaluable outcomes and fail-closed behaviour", "description": "What happens when the instrument cannot be evaluated — missing attributes, unreachable authority record, unverifiable proof, contradictory state — including the distinction between a constraint that is unsatisfied and one that could not be evaluated, and which unevaluable outcomes must raise an operational alert rather than a silent denial.", "source_refs": [ "SRC-001", "SRC-008", "SRC-011" ], "questions": [ { "id": "q-default-outcome", "text": "Is the default outcome denial, and under which narrow, declared conditions may any fallback permit apply?", "kind": "constraint", "answer_data": [ "default outcome", "fallback conditions if any", "approver of each fallback" ] }, { "id": "q-unsatisfied-vs-unevaluable", "text": "How is an unevaluable constraint distinguished from one that was evaluated and not satisfied?", "kind": "validation", "answer_data": [ "outcome discriminator code", "diagnostic reason code", "attribute that could not be resolved" ] }, { "id": "q-diagnostic-leakage", "text": "What diagnostic detail may be returned to the requester without leaking contract content?", "kind": "privacy", "answer_data": [ "permitted reason code set", "prohibited detail list", "internal-only diagnostic channel" ] }, { "id": "q-alerting", "text": "Which unevaluable outcomes must raise an operational alert rather than resolve to a silent denial?", "kind": "exception", "answer_data": [ "alertable reason codes", "alert target", "suppression rules and their review interval" ] } ], "data_elements": [ { "id": "outcome-reason-code", "name": "Outcome reason code", "description": "Coded explanation of why an outcome was reached, distinguishing unsatisfied from unevaluable.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "unresolved-attribute", "name": "Unresolved attribute", "description": "Attribute that could not be obtained during evaluation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Fail-closed behaviour is a declared rule set configured on the decision service, and its per-evaluation output is already carried by the decision response artefact. A separate artefact would duplicate that record and create ambiguity about which one an auditor should read." } ] }, { "id": "conflict-precedence", "name": "Conflict and Precedence", "description": "How several applicable instruments, prohibitions and overriding duties are combined into one defensible outcome.", "source_refs": [ "SRC-001", "SRC-008" ], "findings": [ { "id": "multi-grant-conflict", "name": "Multi-instrument conflict resolution", "description": "The declared strategy for combining a permission with a prohibition, whether a later or narrower instrument supersedes an earlier or broader one, how a conflict between a grant and an overriding legal duty is recorded rather than silently resolved, and whether the strategy is declared on the instrument or fixed by the adopting Dimension.", "source_refs": [ "SRC-001", "SRC-003", "SRC-007", "SRC-008" ], "questions": [ { "id": "q-combining-strategy", "text": "Which combining strategy applies when one instrument permits and another prohibits the same read?", "kind": "decision", "answer_data": [ "strategy identifier", "outcome under the strategy", "precedence order applied" ] }, { "id": "q-narrower-later", "text": "Does a narrower or later instrument automatically supersede a broader or earlier one?", "kind": "constraint", "answer_data": [ "supersession rule", "tie-break rule", "explicit non-supersession cases" ] }, { "id": "q-legal-override", "text": "How is a conflict between the instrument and an overriding legal duty recorded and surfaced?", "kind": "exception", "answer_data": [ "override basis reference", "recorded conflict entry", "notification obligation to the grantor" ] }, { "id": "q-strategy-authority", "text": "Is the combining strategy declared on the instrument or fixed by the adopting Dimension?", "kind": "authority", "answer_data": [ "declaration site", "default strategy when undeclared", "who may change it and under what review" ] } ], "data_elements": [ { "id": "conflict-strategy", "name": "Conflict strategy", "description": "Declared rule for resolving permission-versus-prohibition conflicts, including the option of treating the instrument as invalid.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "precedence-order", "name": "Precedence order", "description": "Ordered list determining which applicable instrument governs when several apply.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "recorded-conflict", "name": "Recorded conflict", "description": "An entry documenting an unresolved or overridden conflict, with its basis and resolution.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "conflict-resolution-declaration", "name": "Conflict resolution declaration", "description": "The published statement of combining strategy and precedence order that every decision point in the Dimension must apply identically.", "media_or_form": [ "policy declaration document", "structured configuration object" ], "serial": false, "identity_strategy": "Governed policy IRI plus semantic version; each version is immutable and the version applied is recorded on every decision response.", "source_refs": [ "SRC-001", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "assurance-and-stewardship", "name": "Assurance and Stewardship", "description": "Trustworthiness of the instrument and its evidence over time: provenance, integrity, retention, and who may read the contract record itself.", "rationale": "GDPR Art 5(2) and Art 30 impose accountability and record-keeping; HIPAA requires signed authorizations to be retained under 164.530(j); the Data Governance Act Art 12 requires logging and forbids intermediaries from using exchanged data for other purposes; VC 2.0 supplies the proof and status pattern. The instrument is itself personal data about the grantor, so access to it must be governed recursively.", "source_refs": [ "SRC-003", "SRC-011", "SRC-012", "SRC-014" ], "layers": [ { "id": "provenance-integrity", "name": "Provenance and Integrity", "description": "Where each record came from, who is accountable for it, and how it is made tamper-evident and comparable.", "source_refs": [ "SRC-003", "SRC-012", "SRC-016" ], "findings": [ { "id": "record-provenance-integrity", "name": "Record provenance and integrity", "description": "The authoritative system of record for each instrument, who created and last changed it, how imported or migrated records are distinguished from natively captured ones, and how the record is canonicalised before hashing or signing so that integrity checks remain stable across storage formats.", "source_refs": [ "SRC-003", "SRC-005", "SRC-012", "SRC-014", "SRC-016" ], "questions": [ { "id": "q-system-of-record", "text": "Which system of record is authoritative for this instrument, and what is its identifier there?", "kind": "provenance", "answer_data": [ "system of record identifier", "native record identifier", "synchronisation state and time" ] }, { "id": "q-canonicalisation", "text": "How is the record canonicalised before it is hashed or signed?", "kind": "quality", "answer_data": [ "canonicalisation algorithm identifier", "field ordering and normalisation rules", "fields excluded from the digest" ] }, { "id": "q-accountability", "text": "Who is accountable for the correctness of each recorded assertion?", "kind": "ownership", "answer_data": [ "accountable role", "named steward reference", "escalation path for disputed assertions" ] }, { "id": "q-import-provenance", "text": "How are imported or migrated records distinguished from natively captured ones?", "kind": "classification", "answer_data": [ "capture origin code", "migration batch reference", "confidence or completeness flag" ] } ], "data_elements": [ { "id": "system-of-record-ref", "name": "System of record reference", "description": "Identifier of the authoritative system holding the master version of the instrument.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "record-digest", "name": "Record digest", "description": "Digest over the canonical form of the record, with the algorithm identifier recorded alongside.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "capture-origin", "name": "Capture origin", "description": "Whether the record was captured natively, imported, or reconstructed, with the batch reference where applicable.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "integrity-manifest", "name": "Integrity manifest", "description": "The digest and signature manifest covering a specific record version, naming the canonicalisation rule applied and the fields it covers.", "media_or_form": [ "signed manifest object", "detached signature", "digest register entry" ], "serial": true, "identity_strategy": "Record identifier plus record version plus digest value; manifests are append-only and never replaced in place.", "source_refs": [ "SRC-012", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "instrument-identity", "name": "Instrument identity", "description": "An access contract MUST have a unique identifier. ODRL requires Policy.uid as an IRI. ISO/IEC TS 27560 requires a record identifier and a schema_version, and a distinct receipt identifier when a receipt is issued. FHIR Consent.identifier is a business identifier for a copy of the statement and is not the FHIR resource id. A calendar date is not an identifier. When the adopting Dimension masters the record, it assigns a UUID or ULID only after master-system and IRI identifiers are absent.", "source_refs": [ "SRC-001", "SRC-017", "SRC-005" ], "questions": [ { "id": "instrument-identity-q01", "text": "What is the canonical identifier of this access contract, in which scheme, and which mastering system assigned it?", "kind": "identity", "answer_data": [ "access_contract_id", "id_scheme", "mastering_system" ] }, { "id": "instrument-identity-q02", "text": "Which information-model profile and schema version interpret the terms of this instrument?", "kind": "interoperability", "answer_data": [ "schema_profile_uri", "schema_version" ] }, { "id": "instrument-identity-q03", "text": "Is this instance the master record, a FHIR copy identifier, or a receipt that only references the record?", "kind": "provenance", "answer_data": [ "instance_role", "source_record_id", "receipt_id" ] } ], "data_elements": [ { "id": "instrument-identity-data01", "name": "access_contract_id", "description": "Canonical instrument identifier. Prefer mastering-system id or ODRL uid IRI.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "instrument-identity-data02", "name": "id_scheme", "description": "Scheme: odrl-uid, iso27560-record-id, fhir-identifier, dimension-ulid.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017", "SRC-005" ] }, { "id": "instrument-identity-data03", "name": "schema_profile_uri", "description": "ODRL profile, DPV-27560 profile, FHIR version, or Dimension profile IRI.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "instrument-identity-data04", "name": "instrument_version", "description": "Version of this instrument, distinct from schema version.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "instrument-identity-data05", "name": "supersedes_contract_id", "description": "Prior instrument this version replaces.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-005" ] } ], "artifacts": [ { "id": "instrument-identity-artifact01", "name": "Instrument header record", "description": "Stable identity envelope: identifiers, schema/profile, version, language, jurisdiction, created and updated observation times.", "media_or_form": [ "canonical-record" ], "serial": false, "identity_strategy": "Keyed by access_contract_id under the mastering-system-first identifier priority; instrument_version distinguishes successive headers.", "source_refs": [ "SRC-001", "SRC-017", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "retention-erasure", "name": "Retention and Erasure", "description": "How long the instrument and its evidence are kept once the grant has ended, and the tension between demonstrability and minimisation.", "source_refs": [ "SRC-003", "SRC-011" ], "findings": [ { "id": "retention-of-records", "name": "Retention and erasure of instrument and evidence", "description": "How long each record class survives termination and on what basis, which fields must be minimised while keeping the record demonstrable, whether an erasure request extinguishes the consent evidence itself, and what remains as a tombstone once the substantive record is gone.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-011" ], "questions": [ { "id": "q-retention-period", "text": "How long must the instrument and its consent evidence be retained after termination, and on what stated basis?", "kind": "retention", "answer_data": [ "retention period per record class", "legal or contractual basis", "review trigger at end of period" ] }, { "id": "q-minimisation", "text": "Which fields must be minimised or redacted while keeping the record capable of demonstrating the act?", "kind": "privacy", "answer_data": [ "minimisable field list", "redaction method", "effect on the integrity digest" ] }, { "id": "q-erasure-vs-evidence", "text": "Does an erasure request from the grantor extinguish the consent evidence itself?", "kind": "exception", "answer_data": [ "erasure scope decision", "competing obligation cited", "documented outcome and its approver" ] }, { "id": "q-tombstone", "text": "What is deleted, what is anonymised, and what remains as a tombstone after the retention period?", "kind": "decision", "answer_data": [ "deleted field set", "anonymised field set", "tombstone field set and its retention" ] } ], "data_elements": [ { "id": "retention-period", "name": "Retention period", "description": "Declared period for which a record class is retained after termination.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-011" ] }, { "id": "retention-basis", "name": "Retention basis", "description": "Stated justification for retaining a record class beyond the life of the grant.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "disposal-state", "name": "Disposal state", "description": "Whether a record is live, minimised, anonymised, tombstoned or destroyed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "retention-schedule", "name": "Retention schedule", "description": "The governed table mapping each record class to its retention period, basis, minimisation rule and disposal outcome.", "media_or_form": [ "tabular schedule", "structured policy object" ], "serial": false, "identity_strategy": "Dimension-scoped schedule identifier plus semantic version; the version applied is recorded on each disposal action.", "source_refs": [ "SRC-003", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "contract-record-access", "name": "Access to the Contract Record", "description": "Governing reads of the instrument itself, which contains personal data about the grantor and commercially sensitive terms.", "source_refs": [ "SRC-003", "SRC-009", "SRC-014" ], "findings": [ { "id": "access-to-contract-record", "name": "Access to the instrument and its evidence", "description": "The recursive problem: who may read the instrument as opposed to merely relying on a validity token, which projection each role receives, whether a grantee may learn about other grantees or other grants, and how supervisory or regulator access is authorised and logged.", "source_refs": [ "SRC-003", "SRC-008", "SRC-009", "SRC-014" ], "questions": [ { "id": "q-who-reads-contract", "text": "Who may read the full instrument, and who may receive only a validity token?", "kind": "access", "answer_data": [ "role to projection mapping", "default projection for unlisted roles", "approval required for full access" ] }, { "id": "q-projection-per-role", "text": "Which named projection does each role receive, and what does each omit?", "kind": "access", "answer_data": [ "projection name", "included field set", "explicitly omitted field set" ] }, { "id": "q-cross-grantee-visibility", "text": "May a grantee learn the identity of other grantees or the existence of other grants over the same objects?", "kind": "privacy", "answer_data": [ "visibility rule", "aggregation and inference safeguards", "exception conditions" ] }, { "id": "q-regulator-access", "text": "How is supervisory or regulator access authorised, bounded and logged?", "kind": "authority", "answer_data": [ "authorising instrument reference", "permitted scope and duration", "logging and grantor notification rules" ] } ], "data_elements": [ { "id": "projection-name", "name": "Projection name", "description": "Named disclosure shape applied when the instrument itself is read.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "contract-read-role", "name": "Contract read role", "description": "Role permitted to read some projection of the instrument.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "regulator-access-basis", "name": "Regulator access basis", "description": "Recorded authorisation under which a supervisory body read the instrument.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "contract-projection-profile", "name": "Contract projection profile", "description": "The declared set of named projections over the instrument — validity token, grantor ledger, grantee entitlement list — each with its included and omitted fields.", "media_or_form": [ "structured projection definition", "tabular field map" ], "serial": false, "identity_strategy": "Projection name as a governed IRI plus semantic version; each read of the instrument records which projection version was applied.", "source_refs": [ "SRC-009", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "interoperability", "name": "Interoperability and Jurisdiction", "description": "Declared, evidence-backed mappings to external standards, and the parameters that change with the governing legal regime.", "rationale": "External standards are alignments, not conformance: ODRL, ISO/IEC TS 27560 with DPV, FHIR Consent, XACML, RFC 9396 and DUO each cover part of the surface with different vocabularies and different state models. HIPAA 164.508 shows that the instrument itself changes form across regimes, so jurisdiction must be an explicit parameter rather than an assumption.", "source_refs": [ "SRC-001", "SRC-005", "SRC-007", "SRC-008", "SRC-011", "SRC-013" ], "layers": [ { "id": "standards-alignment", "name": "Standards Alignment", "description": "Crosswalks to external vocabularies with explicit statements of fidelity and loss.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-010" ], "findings": [ { "id": "standards-alignment-map", "name": "Standards alignment and conformance claims", "description": "Which external concept each core element maps to and at what fidelity, which mappings lose information and in which direction, whether any conformance claim is asserted and on what evidence, and the fallback when a target standard has no equivalent concept.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-010", "SRC-011", "SRC-013" ], "questions": [ { "id": "q-mapping-fidelity", "text": "To which external standard concept does each core element map, and at what fidelity?", "kind": "interoperability", "answer_data": [ "source element", "target standard and version", "target concept identifier", "fidelity rating" ] }, { "id": "q-mapping-loss", "text": "Which mappings are lossy, and precisely what is lost in each direction?", "kind": "quality", "answer_data": [ "lossy mapping identifier", "lost element per direction", "mitigating carrier field" ] }, { "id": "q-conformance-claim", "text": "Is a conformance claim asserted against any target standard, and what evidence supports it?", "kind": "evidence", "answer_data": [ "claim statement or explicit absence", "test or audit evidence reference", "claim scope and expiry" ] }, { "id": "q-no-equivalent", "text": "What is the fallback when a target standard has no equivalent concept for a required element?", "kind": "exception", "answer_data": [ "extension mechanism used", "profile or namespace identifier", "interoperability warning raised to consumers" ] } ], "data_elements": [ { "id": "alignment-target", "name": "Alignment target", "description": "External standard and version a mapping points at.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "mapping-fidelity", "name": "Mapping fidelity", "description": "Declared fidelity of a mapping: exact, broader, narrower, related, or none.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "conformance-claim", "name": "Conformance claim", "description": "Any asserted conformance statement, with its supporting evidence reference; absent by default.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "alignment-crosswalk", "name": "Alignment crosswalk", "description": "The versioned mapping table from this model's elements to external standard concepts, with fidelity, direction and loss recorded per row.", "media_or_form": [ "mapping table", "structured alignment object", "linked-data mapping graph" ], "serial": false, "identity_strategy": "Composite of this model's version and the target standard version; a new crosswalk row set is issued whenever either side changes version.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "jurisdictional-variance", "name": "Jurisdictional Variance", "description": "The parameters that must be supplied per legal regime before the instrument can be validated at all.", "source_refs": [ "SRC-003", "SRC-011", "SRC-014" ], "findings": [ { "id": "jurisdictional-parameters", "name": "Jurisdictional parameters and instrument form", "description": "Which law governs the instrument, which authority is competent, whether consent or a differently-shaped authorization is the correct instrument, the age threshold at which a person may consent for themselves, whether conditioning a service on the grant is permitted, and which cross-border transfer conditions attach to the covered read.", "source_refs": [ "SRC-003", "SRC-004", "SRC-011", "SRC-014", "SRC-015" ], "questions": [ { "id": "q-governing-law", "text": "Which law governs this instrument, and which supervisory authority is competent over it?", "kind": "authority", "answer_data": [ "governing law identifier", "competent authority reference", "choice-of-law basis" ] }, { "id": "q-instrument-form", "text": "In this jurisdiction, is the correct instrument a consent, an authorization, or another form with different mandatory elements?", "kind": "classification", "answer_data": [ "instrument form code", "mandatory element set for that form", "validity defect list for that form" ] }, { "id": "q-age-threshold", "text": "What is the age at which a person may grant for themselves in this jurisdiction, and how is a lower age handled?", "kind": "constraint", "answer_data": [ "age threshold", "verification method for parental responsibility", "behaviour when age is unknown" ] }, { "id": "q-transfer-conditions", "text": "Which cross-border transfer conditions attach to a read performed outside the originating jurisdiction?", "kind": "spatial", "answer_data": [ "permitted destinations", "required safeguard instrument", "record of the safeguard relied on" ] } ], "data_elements": [ { "id": "governing-law", "name": "Governing law", "description": "Identifier of the legal regime under which the instrument is validated and interpreted.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-011" ] }, { "id": "instrument-form-code", "name": "Instrument form", "description": "The jurisdiction-specific form the instrument takes, which determines its mandatory element set.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-003" ] }, { "id": "self-grant-age-threshold", "name": "Self-grant age threshold", "description": "Age at or above which the data subject may grant without a holder of parental responsibility.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "transfer-safeguard-ref", "name": "Transfer safeguard reference", "description": "Reference to the safeguard relied on for a read that crosses a jurisdictional boundary.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "jurisdiction-profile", "name": "Jurisdiction profile", "description": "The per-regime parameter set — instrument form, mandatory elements, age threshold, conditioning rules, transfer conditions, retention floor — that a validator loads before assessing an instrument.", "media_or_form": [ "structured parameter set", "tabular profile register" ], "serial": false, "identity_strategy": "Territory or legal-regime identifier plus profile version; the profile version applied is recorded on every validity assessment.", "source_refs": [ "SRC-003", "SRC-011", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "instrument-flavour-classification", "name": "Instrument classification", "description": "The same mixin covers several disjoint subtypes that MUST be classified rather than conflated: ODRL Set (generic rules), Offer (assigner offers, does not grant), Agreement (assigner has granted to assignee); FHIR privacy consent directive versus treatment or research-participation consent; ISO 27560 consent record (privacy processing) versus a non-personal usage licence. FHIR decision is permit or deny as the default, with nested provisions as exceptions. ODRL Policy may declare a conflict strategy (perm, prohibit, invalid). Regulatory basis and category support indexing but do not themselves grant access.", "source_refs": [ "SRC-001", "SRC-003", "SRC-017" ], "questions": [ { "id": "instrument-flavour-classification-q01", "text": "Is this instrument an Offer, an Agreement already granted, a FHIR draft, or a mere Set of rules?", "kind": "classification", "answer_data": [ "policy_subclass", "status" ] }, { "id": "instrument-flavour-classification-q02", "text": "Does this grant authorise processing of personal data on a consent legal basis, or only usage of a non-personal asset?", "kind": "classification", "answer_data": [ "grant_flavour", "regulatory_basis_codes" ] }, { "id": "instrument-flavour-classification-q03", "text": "If a requested read matches no provision, is the default permit, deny, or invalid-by-conflict?", "kind": "decision", "answer_data": [ "default_decision", "conflict_strategy" ] } ], "data_elements": [ { "id": "instrument-flavour-classification-data01", "name": "policy_subclass", "description": "set | offer | agreement | fhir-consent | iso27560-record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017", "SRC-005" ] }, { "id": "instrument-flavour-classification-data02", "name": "grant_flavour", "description": "privacy-consent | usage-licence | mixed-only-if-principal-is-grantor.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "instrument-flavour-classification-data03", "name": "default_decision", "description": "permit | deny. FHIR Consent.decision; ODRL implies only stated permissions.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017" ] }, { "id": "instrument-flavour-classification-data04", "name": "conflict_strategy", "description": "ODRL perm | prohibit | invalid.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "instrument-flavour-classification-data05", "name": "category_codes", "description": "FHIR consent category; DPV consent type.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-019" ] }, { "id": "instrument-flavour-classification-data06", "name": "regulatory_basis_codes", "description": "FHIR regulatoryBasis or DPV legal-basis IRI, e.g. GDPR Art 6(1)(a).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-017", "SRC-019" ] } ], "artifacts": [ { "id": "instrument-flavour-classification-artifact01", "name": "Classification block", "description": "Typed flags that tell evaluators which rule family and default decision to apply.", "media_or_form": [ "inline-metadata" ], "serial": false, "identity_strategy": "Carried inline on the instrument header and addressed through access_contract_id; no separate identifier.", "source_refs": [ "SRC-001", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "verify-grantor-authority", "name": "Verify grantor authority", "description": "Check that the asserted grantor could lawfully permit the read, in the capacity claimed, against the ownership or delegation record, and record the outcome and time.", "inputs": [ "grantor identifier", "claimed capacity code", "covered object references", "authority evidence references" ], "outputs": [ "verification outcome", "verified capacity scope", "verification timestamp", "authority verification record reference" ], "preconditions": [ "Grantor identifier resolves in a named master system", "Ownership or delegation record is reachable, or an explicit unreachable outcome is produced" ], "effects": [ "Authority verification record is created", "Instrument is blocked from activation if verification fails" ], "source_refs": [ "SRC-003", "SRC-007", "SRC-011" ] }, { "id": "draft-grant", "name": "Draft grant instrument", "description": "Assemble a proposed instrument from parties, scope clauses, purpose, permitted actions, constraints and duties, and validate it against the applicable jurisdiction profile without activating it.", "inputs": [ "grantor and grantee references", "scope clause set", "purpose codes and text", "permitted and prohibited actions", "constraints and duties", "jurisdiction profile version" ], "outputs": [ "draft instrument with version identifier", "validation report of missing mandatory elements" ], "preconditions": [ "Jurisdiction profile is resolvable", "Scope selectors meet the declared specificity floor" ], "effects": [ "Instrument is created in a proposed state", "No read becomes permissible" ], "source_refs": [ "SRC-001", "SRC-007", "SRC-011" ] }, { "id": "capture-consent", "name": "Capture consent act", "description": "Record an act of assent with its capture context, notice version, act time and record time, and assess it against the validity elements required by the governing regime.", "inputs": [ "draft instrument reference", "indication mechanism", "notice version reference", "language tag", "acting party and capacity", "act timestamp" ], "outputs": [ "consent record", "validity assessment", "consent status" ], "preconditions": [ "Notice version snapshot exists and is immutably retrievable", "Acting party capacity has been verified" ], "effects": [ "Consent record is appended", "Instrument becomes eligible for activation where consent is the declared basis" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-016" ] }, { "id": "activate-grant", "name": "Activate grant", "description": "Move a validated instrument into force from a stated instant, fixing the version that governs and publishing its validity for decision points.", "inputs": [ "instrument version reference", "basis reference (consent record or other legal basis)", "requested effective instant" ], "outputs": [ "active instrument state", "effective-from timestamp", "activation event" ], "preconditions": [ "Authority verification succeeded", "All mandatory elements for the jurisdiction profile are present", "Any pre-condition duties are discharged" ], "effects": [ "Reads within scope become permissible from the effective instant", "Activation event is emitted to the audit model" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-007" ] }, { "id": "issue-receipt", "name": "Issue receipt to grantor", "description": "Produce and deliver the durable, portable copy of what was agreed, including the withdrawal method and a checkable status reference.", "inputs": [ "consent record reference", "instrument version reference", "grantor delivery channel" ], "outputs": [ "consent receipt artefact", "delivery confirmation", "receipt status endpoint reference" ], "preconditions": [ "Consent record exists and passes integrity check", "Delivery channel is known and validated" ], "effects": [ "Receipt is issued and its status becomes checkable", "Delivery is recorded against the consent record" ], "source_refs": [ "SRC-012", "SRC-014", "SRC-015", "SRC-016" ] }, { "id": "evaluate-coverage", "name": "Evaluate coverage of a proposed read", "description": "Given a proposed read, determine whether an in-force instrument covers it, apply constraints and the declared conflict strategy, and return an outcome with any obligations and a validity horizon.", "inputs": [ "requesting party identifier and assurance level", "target object references", "proposed action code", "declared purpose code", "evaluation context attributes" ], "outputs": [ "decision outcome", "returned obligations", "scope fingerprint", "validity horizon", "decision correlation identifier" ], "preconditions": [ "Required attributes are supplied or an unevaluable outcome is produced", "Conflict resolution declaration version is resolvable" ], "effects": [ "Decision response is produced", "Decision correlation identifier is emitted for audit logging", "No contract content is disclosed to the requester" ], "source_refs": [ "SRC-008", "SRC-009", "SRC-010" ] }, { "id": "amend-instrument", "name": "Amend instrument", "description": "Apply a classified change to a live instrument, creating a new version, and require a fresh consent act where the change class demands one.", "inputs": [ "instrument version reference", "proposed change set", "change classification", "authority of the amending party" ], "outputs": [ "new instrument version", "amendment record", "re-consent requirement flag" ], "preconditions": [ "Instrument is in a state that permits amendment", "Amending party holds the required authority" ], "effects": [ "New version supersedes the prior version from a stated instant", "Prior version is retained and remains resolvable" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-011" ] }, { "id": "terminate-instrument", "name": "Terminate instrument", "description": "End a grant by withdrawal, revocation, expiry, supersession or invalidation, recording the reason, the effective instant and any reliance exception.", "inputs": [ "instrument reference", "termination reason code", "issuing party", "requested effective instant" ], "outputs": [ "revocation or termination notice", "updated state", "effective instant" ], "preconditions": [ "Issuing party is authorised for the stated reason", "Effective instant is not earlier than any binding non-retroactivity rule permits" ], "effects": [ "No further read is covered from the effective instant", "Prior lawful reads remain lawful unless a stated rule provides otherwise", "Post-termination surviving duties become active" ], "source_refs": [ "SRC-003", "SRC-006", "SRC-011" ] }, { "id": "propagate-termination", "name": "Propagate termination downstream", "description": "Notify every recipient that received data under the grant, collect cutoff and deletion acknowledgements, and record any recipient that cannot be reached.", "inputs": [ "termination event reference", "recipient list or recipient categories", "notification deadline" ], "outputs": [ "propagation ledger entries", "propagation status", "impossibility justifications" ], "preconditions": [ "Termination event exists", "Recipient contact routes are known or an impossibility record is produced" ], "effects": [ "Recipients are notified within the deadline", "Unresolved recipients are surfaced to the accountable steward" ], "source_refs": [ "SRC-003", "SRC-013", "SRC-014" ] }, { "id": "record-duty-discharge", "name": "Record duty discharge", "description": "Register that a grantee duty was fulfilled, with the evidence relied on, and update the duty status.", "inputs": [ "duty reference", "evidence artefact", "discharging party", "discharge timestamp" ], "outputs": [ "obligation discharge evidence artefact", "updated duty status" ], "preconditions": [ "Duty exists and is not already discharged", "Evidence type is acceptable for the duty class" ], "effects": [ "Duty status changes to discharged", "Any dependent suspension is lifted" ], "source_refs": [ "SRC-001", "SRC-013" ] }, { "id": "project-contract-view", "name": "Project a view of the instrument", "description": "Return a named projection of the instrument to a requesting role — validity token, grantor ledger or grantee entitlement list — omitting everything outside that projection.", "inputs": [ "instrument reference", "requesting role", "projection name and version" ], "outputs": [ "projected view", "applied projection version", "access log entry reference" ], "preconditions": [ "Requesting role is mapped to the requested projection", "Projection profile version is resolvable" ], "effects": [ "Only the projected fields are disclosed", "The read of the instrument is itself logged in the audit model" ], "source_refs": [ "SRC-008", "SRC-009", "SRC-014" ] }, { "id": "apply-retention-disposal", "name": "Apply retention and disposal", "description": "Evaluate the retention schedule against terminated instruments and their evidence, and minimise, anonymise, tombstone or destroy each record class accordingly.", "inputs": [ "record class", "termination timestamp", "retention schedule version", "competing obligation references" ], "outputs": [ "disposal state", "disposal action record", "surviving tombstone field set" ], "preconditions": [ "Retention period has elapsed or an erasure request has been assessed", "No competing legal hold applies, or the hold is recorded" ], "effects": [ "Records are minimised, anonymised, tombstoned or destroyed", "Integrity manifests for destroyed records are retained as evidence of prior existence" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-011" ] }, { "id": "conflict-evaluation", "name": "Conflict evaluation", "description": "Detect Permission/Prohibition/Action-inheritance clashes and apply the instrument's conflict strategy or fail invalid.", "inputs": [ "access_contract_id", "candidate_action", "candidate_target" ], "outputs": [ "conflict_detected", "conflict_strategy_applied", "resulting_decision" ], "preconditions": [ "Rules and action includedIn/implies graph are available." ], "effects": [ "Does not change stored rules.", "Returns invalid when strategy is invalid or when privacy default-deny forbids perm-overrides-prohibition without an explicit profile." ], "source_refs": [ "SRC-001" ] } ], "composition": [ { "target": "Any world-model entry whose data may cross an ownership or accountability boundary", "relation": "MIX-IN", "purpose": "Attach permission, consent, lifecycle and decision semantics to a host entry without the host having to redefine them; the host contributes only the object references that scope clauses select over.", "required": false, "source_refs": [ "SRC-001", "SRC-007" ] }, { "target": "world.ownership — ownership, title and delegation model (legacy S1)", "relation": "REFERENCE", "purpose": "Resolve whether the grantor held the right to permit, and in which capacity; a grant whose authority basis fails verification is void here and corrected there.", "required": true, "source_refs": [ "SRC-003", "SRC-011" ] }, { "target": "world.disclosureScope — disclosure shape and projection policy model (legacy S3)", "relation": "REFERENCE", "purpose": "Each scope clause points at a projection policy identifier that determines the shape in which covered objects leave; this model never describes shape itself.", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "target": "world.accessAudit — access audit model (legacy S4)", "relation": "REFERENCE", "purpose": "Every decision rendered, every exercise of a grant and every read of the instrument itself is logged there against the decision correlation identifier produced here.", "required": true, "source_refs": [ "SRC-008", "SRC-014" ] }, { "target": "world.accessEnforcement — enforcement and violation model (legacy S7)", "relation": "REFERENCE", "purpose": "Undischarged duties and out-of-scope reads escalate into cases there; this model contributes the duty definition, its deadline and its discharge status.", "required": false, "source_refs": [ "SRC-001", "SRC-013" ] }, { "target": "Generic contract primitive (parties, terms, formation, termination)", "relation": "EXTEND", "purpose": "This model specialises the general agreement primitive for permission to read, adding consent evidence, capacity verification and a coverage-decision surface that a generic contract does not carry.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "ODRL Information Model 2.2 and ODRL Vocabulary & Expression 2.2", "relation": "ALIGN", "purpose": "Map the instrument onto Policy/Agreement, Permission, Prohibition and Duty with assigner, assignee, target, action and constraint; adopt the conflict strategy vocabulary. No conformance is claimed, since ODRL carries no consent-evidence, capacity or state-machine concepts.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "ISO/IEC TS 27560:2023 consent record information structure, as rendered by the DPVCG guide with DPV 2.1", "relation": "ALIGN", "purpose": "Map the consent record and receipt onto the standardised record structure, event fields and consent status vocabulary so records can be exchanged and lifecycle-managed across systems.", "required": false, "source_refs": [ "SRC-005", "SRC-006", "SRC-016" ] }, { "target": "HL7 FHIR R5 Consent resource", "relation": "ALIGN", "purpose": "Map grantor, grantee, manager, controller, verification, decision and nested provisions for health-sector exchange; note the state vocabularies are not isomorphic with DPV.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "OASIS XACML 3.0", "relation": "ALIGN", "purpose": "Adopt the separation of decision point from enforcement point, the four-value outcome vocabulary and obligation expressions as the semantics of the coverage-decision surface.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "Kantara UMA 2.0 grant and IETF RFC 9396 authorization details", "relation": "ALIGN", "purpose": "Project a standing instrument into runtime tokens and fine-grained authorization details, so an enforcing party can act on the granted scope and actions without reading the instrument.", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "target": "W3C Verifiable Credentials Data Model 2.0", "relation": "ALIGN", "purpose": "Express the receipt as an independently verifiable credential with validFrom, validUntil, evidence, termsOfUse and a checkable credentialStatus supporting revocation and suspension.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "GA4GH / OBO Data Use Ontology (DUO)", "relation": "ALIGN", "purpose": "Supply governed purpose codes and use modifiers for research data access, demonstrating that purposes and duties are coded reference data rather than free text.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "Privacy notice and transparency model", "relation": "REFERENCE", "purpose": "Resolve the exact notice version presented at capture; this model stores only an immutable snapshot as evidence and never becomes the master of notice text.", "required": false, "source_refs": [ "SRC-005", "SRC-015" ] }, { "target": "Purpose, data category and action vocabularies registry", "relation": "COMPOSE", "purpose": "Coded purposes, data categories, actions and duties are resolved from governed vocabularies whose versions are recorded on the instrument; the model composes them rather than embedding copies.", "required": true, "source_refs": [ "SRC-006", "SRC-013", "SRC-002" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a single accountable steward for each instrument class and publish the escalation path for disputed assertions; the default steward for an instrument is the grantor.", "The Dimension must publish, and version, the jurisdiction profiles, the conflict resolution declaration, the retention schedule and the contract projection profiles before any instrument may be activated under it.", "The Dimension must declare which governed vocabularies supply purpose codes, data category codes, action codes and duty codes, pinning the version in force, and must record that version on every instrument it activates.", "The Dimension must operate or designate a decision service that implements the declared outcome vocabulary and fail-closed default, and must not permit enforcement points to read instrument content directly.", "The Dimension must not create permission on a grantor's behalf beyond what the ownership and delegation model records as delegated authority." ], "namespace_guidance": "Use a stable reverse-domain or registry-rooted namespace per Dimension, with the model segment fixed as the access-contract namespace and sub-namespaces for agreement, consent, lifecycle, decision, assurance and interoperability concerns. Instrument identifiers are minted inside the Dimension namespace; purpose, action, data category and duty terms are referenced by their owning vocabulary's IRI and are never minted locally except through a declared extension namespace that is explicitly marked non-interoperable.", "registry_links": [ "Registry entry vr.wm-xct-002 (WM-XCT-002) is the canonical record of this mixin, its status and its review state.", "Sibling registry entries for the ownership, disclosure-scope, access-audit and enforcement models must be resolvable before an instrument is activated, since three of the four are required composition targets.", "Governed vocabulary registrations for purpose, action, data category and duty terms must be listed with pinned versions in the Dimension's package manifest." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form of an instrument or consent record is the abstract field set with values in their declared value kinds; storage encodings such as JSON, YAML, Markdown, XML or a document store are projections and never authoritative.", "All time values are normalised to RFC 3339 with seconds and an explicit offset or Z before canonicalisation; a value lacking an offset is rejected rather than assumed to be UTC.", "Field ordering is normalised deterministically and collections are ordered by their declared key before a digest is computed; the canonicalisation algorithm identifier and version are recorded alongside every digest.", "Fields excluded from the digest — such as transient synchronisation state and cache metadata — are enumerated explicitly in the integrity manifest, never inferred.", "Coded values are canonicalised as the full governed IRI plus the pinned vocabulary version, not as a local short code." ], "patch_rules": [ "Instruments and consent records are append-only: a change produces a new version that names its predecessor, and no prior version is mutated or deleted while its retention period runs.", "A patch must declare its change class, because the class determines whether re-consent is required before the new version may activate.", "Corrections to a recorded timestamp or assertion are expressed as a correction event carrying the superseded value, the corrector identity and the correction time; the original value remains readable.", "Consent events, propagation ledger entries, obligation discharges and integrity manifests are strictly append-only and admit no patch operation at all.", "A patch that would narrow scope takes effect from its stated instant forward and never retroactively invalidates a read already performed under the prior version." ], "compatibility_rules": [ "Adding an optional field, a new coded term or a new named projection is a minor change; removing a field, narrowing cardinality, changing a value kind, altering the state set or changing the fail-closed default is a breaking change requiring a major version.", "The schema version is carried on every instrument and consent record so that a consumer can refuse to interpret a version it does not understand rather than guessing.", "Alignment crosswalks are versioned against both this model's version and the target standard's version; a version change on either side invalidates the crosswalk row set until it is re-issued.", "Locally minted extension terms must be namespaced and marked non-interoperable; a consumer that does not recognise an extension must treat any rule depending on it as unevaluable, not as satisfied.", "Conformance to an external standard is never asserted by default; a claim may be recorded only with a scoped evidence reference and an expiry." ] }, "artifact_rules": { "identity_priority": [ "An identifier assigned by the authoritative master system of record for the instrument, the consent act or the party, where one exists.", "A governed global identifier or IRI from a registered namespace, such as a vocabulary term IRI, a notice IRI or a receipt URI operated by the Dimension.", "A UUID or ULID minted by the adopting Dimension, used only when neither of the above exists, and always recorded together with the system that minted it.", "A date, a timestamp, a natural-language label or a filename is never an identifier; a consent timestamp in particular must not be used to identify a consent record." ], "timestamp_rule": "All time values are recorded in RFC 3339 format with seconds and an explicit UTC offset or the Z designator. Event time (when the act or state change occurred) and observation or ingestion time (when it was recorded) are stored as separate fields whenever they can differ, and the decision time of a coverage evaluation is stored separately from both.", "serial_naming_rule": "Serial artefacts — consent records, receipts, revocation notices, amendment records, obligation discharge evidence, decision responses, integrity manifests and propagation ledger entries — are named as the identifier of their governing object plus a monotonic sequence or version segment, never by date and never by a counter that is reset. Non-serial artefacts — scope clause sets, purpose statements, constraint expression sets, state transition tables, conflict resolution declarations, retention schedules, projection profiles, crosswalks and jurisdiction profiles — are named by their governed identifier plus a semantic version, and every published version remains resolvable.", "integrity_rule": "Every artefact carries a digest over its canonical form, the canonicalisation algorithm identifier and the field set covered. Consent records, receipts and revocation notices additionally carry a proof binding them to the acting or issuing party, and that proof must be independently verifiable by a party that does not trust the storage system. Integrity is re-verified on export, on migration and on any restoration from backup, and a failed check makes the artefact unevaluable rather than merely suspect." }, "policies": [ "Fail closed: if coverage cannot be established, the outcome is denial. A permit is produced only from an instrument that is in force, whose authority basis verified, whose constraints all evaluated true, and whose governing vocabulary versions resolved.", "Consent is a basis, not a universal precondition: an instrument may rest on consent, contract, statute or a court order. Where the declared basis is consent, the full consent apparatus is mandatory; where it is not, the consent bundle is absent and the declared basis is recorded with its reference.", "Minimum disclosure on the decision surface: an enforcing party receives an outcome, its obligations, a scope fingerprint and a validity horizon, and never the parties, purpose text or terms of the instrument.", "Non-retroactivity by default: termination ends coverage from its effective instant forward and does not, by itself, render prior reads unlawful; any retroactive effect must be stated explicitly with its basis.", "Recursive governance: reading the instrument is itself an access event, governed by a named projection and logged in the audit model; the grantor is the default steward of instruments over their own objects.", "No silent conformance: alignments to external standards are declared with fidelity and loss, and a conformance claim is recorded only with scoped evidence and an expiry.", "Fail closed: unknown status, missing authority reference, unfulfilled pre-condition duty, purpose mismatch, expired window, or unverified child-capacity yields deny.", "Do not treat a stored record or receipt as legally valid consent until quality flags are assessed. Alignment with ODRL, ISO, FHIR, DPV or Kantara is not conformance.", "Withdrawal is as easy as giving consent; withdrawal is not retroactive; post-termination duties still run.", "Token and cache lifetimes MUST NOT exceed the grant window and MUST be revoked on withdrawal even if refresh would otherwise mint new access without re-assessment." ], "crud": { "read": [ "Reads of an instrument are served through a named projection; the default projection for an unlisted role is the validity token, which discloses only whether coverage exists and a scope fingerprint.", "The grantor may read the full instrument and every consent record and receipt relating to it, plus the ledger of everything they have granted and to whom.", "A grantee may read its own entitlement projection and may not learn of other grantees or of other instruments over the same objects.", "Supervisory access is served under a recorded authorising instrument with a bounded scope and duration, and is logged like any other read." ], "create": [ "An instrument is created in a proposed state only; creation never confers permission.", "A consent record may be created only with a resolvable notice version snapshot, an act time and a record time, and an identified acting party with verified capacity.", "Activation is a separate operation from creation and requires successful authority verification and a complete mandatory element set for the governing jurisdiction profile.", "Receipts are created only from an existing consent record that passes its integrity check." ], "update": [ "Substantive change produces a new version; in-place update is limited to declared non-substantive fields such as contact routing and synchronisation state.", "A change class that triggers re-consent blocks activation of the new version until a fresh consent act is captured.", "State transitions are applied only along the published transition table, and each records its effective instant separately from its record time.", "Consent records, receipts, revocation notices, discharge evidence and ledger entries are never updated; corrections are appended." ], "delete": [ "Instruments and consent records are not deleted on request; they are terminated, then minimised, anonymised, tombstoned or destroyed according to the published retention schedule.", "An erasure request affecting consent evidence is assessed against the competing obligation to be able to demonstrate the act, and the outcome and its approver are recorded.", "When a record is destroyed, its integrity manifest and a tombstone naming the identifier, class and disposal time are retained as evidence that it existed.", "Destruction of an instrument does not discharge post-termination surviving duties; those remain tracked until they lapse or are discharged." ] }, "roles": [ { "name": "Grantor (data owner or their verified representative)", "responsibilities": [ "Decides whether an instrument is offered, accepted, amended or terminated", "Is the default steward of every instrument over their own objects", "Receives the receipt and the ledger projection, and may withdraw through at least the channels by which they granted" ] }, { "name": "Grantee (reader)", "responsibilities": [ "Exercises reads only within scope, purpose and permitted actions", "Discharges duties by their deadlines and supplies the required evidence", "Ceases reading and confirms cutoff on notification of termination" ] }, { "name": "Instrument steward / registrar", "responsibilities": [ "Maintains the completeness, versioning and integrity of instruments and consent records", "Runs authority verification and blocks activation where it fails", "Operates propagation on termination and resolves unreached recipients" ] }, { "name": "Decision service operator", "responsibilities": [ "Implements the published outcome vocabulary, conflict strategy and fail-closed default identically at every decision point", "Emits decision correlation identifiers for audit and enforces the minimum-disclosure response shape", "Raises operational alerts for unevaluable outcomes rather than resolving them silently" ] }, { "name": "Compliance and jurisdiction owner", "responsibilities": [ "Publishes and versions jurisdiction profiles, retention schedules and projection profiles", "Assesses erasure requests against demonstrability obligations and records the outcome", "Reviews and dates any conformance claim and withdraws it when its evidence lapses" ] }, { "name": "Interoperability maintainer", "responsibilities": [ "Maintains alignment crosswalks against pinned external standard versions and records fidelity and loss", "Pins governed vocabulary versions in the package manifest and manages migrations when they change", "Marks locally minted extension terms as non-interoperable and tracks their retirement" ] } ], "access": { "default_rule": "Deny by default at every scope. Access to any part of this model is granted only to a role explicitly mapped to a named projection, and the grantor's own instruments are readable in full only by the grantor, their verified representative and the instrument steward acting within a recorded mandate.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Supervisory or regulatory access under a recorded authorising instrument, bounded in scope and duration, with the grantor notified unless the authorising instrument forbids it.", "Emergency or break-glass read where a stated safety condition applies, permitted only if the Dimension has published the condition in advance, and always producing a high-priority audit event and a post-hoc review.", "Decision-service internal access to full instrument content, which is confined to the decision process and must not be returned to any enforcing party.", "Integrity and retention automation, which may read identifiers, digests and disposal state across all instruments but not scope, purpose or consent content.", "Legal hold, which suspends disposal actions and is itself recorded with its basis, scope and expected duration.", "Supervisory authority or court order under a non-consent legal basis.", "Enforcer need-to-know for a named evaluation request.", "Principal receiving their own receipt.", "Emergency break-glass is not modelled here; if used, it is an enforcement-sibling exception and cannot mint a backdated consent." ], "audit_requirements": [ "Every coverage decision is logged with its correlation identifier, outcome, the instrument version and vocabulary versions evaluated, and the decision time; the log lives in the sibling audit model.", "Every read of an instrument or consent record is logged with the requesting role, the projection name and version applied, and the reason where the read was under an exception.", "Every state transition, amendment, termination, propagation notification and disposal action is logged with its actor, effective instant and record time.", "Break-glass and supervisory reads generate a distinct, high-priority event that is reviewed on a published cadence and reported to the grantor where permitted.", "Audit records are append-only and retained at least as long as the instrument and consent evidence they describe.", "Log every create, activate, amend, verify, receipt, withdraw and duty-discharge with event time, recorded time, actor and outcome.", "Retain demonstration packs at least as long as the processing they authorised plus applicable statutory limitation.", "Integrity failures on the master record are themselves auditable incidents." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Schema version and compatibility policy", "Pinned governed vocabulary versions", "Jurisdiction profile registry URL", "Default outcome and fail-closed statement", "Steward and escalation contact" ], "read_order": [ "AGENTS.md — establishes name, type, and the four resolvable URLs before anything else is interpreted", "Specification URL — the format-neutral model definition: bundles, layers, findings, data elements and their semantics", "Storage type URL — how the abstract model is projected into the storage in use, whether document store, versioned files, graph or relational, and which fields are excluded from digests", "Interface URL — the coverage-decision surface, the projection endpoints and the minimum-disclosure response shape", "Processes URL — the operational procedures: authority verification, consent capture, activation, amendment, termination, propagation, disposal and alert handling", "Jurisdiction profile registry — loaded before any instrument is validated, since it determines the mandatory element set" ] } }, "coverage": { "claim": "Synthesis on the Claude boundary covers the permission instrument, the consent act and its evidence, instrument lifecycle including termination propagation, the coverage-decision and conflict-precedence surface, provenance, retention and recursive access to the instrument, and jurisdictional parameters, plus four Grok findings and one Grok function. Grounding is deepest for the EU/GDPR regime with a US health-sector counterexample and a healthcare FHIR profile; this is not a claim of completeness for any regime, and no conformance to any external standard is asserted.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Grantor, grantee, instrument version, consent record and receipt each carry an explicit identity strategy with a stated priority order: master-system identifier, then governed IRI, then Dimension-minted UUID or ULID. The rule that a consent timestamp is not an identifier is stated explicitly, following the 27560/DPV recommendation of a distinct UUID record identifier." }, { "dimension": "lifecycle", "status": "covered", "notes": "An enumerated state set with a published transition table, separate treatment of proposal, activation, suspension, amendment, supersession, expiry, withdrawal and revocation, plus re-consent triggers and refresh intervals. Grounded in DPV consent statuses, FHIR Consent.status, ODRL Request/Offer/Agreement and VC credentialStatus." }, { "dimension": "relationships", "status": "covered", "notes": "Grantor-to-instrument, instrument-to-scope-clause, clause-to-projection-policy, consent-record-to-instrument, duty-to-grantee, revocation-to-instrument and recipient-to-propagation-ledger are all modelled, with four external sibling models declared as reference targets and three of them required." }, { "dimension": "temporal", "status": "covered", "notes": "Act time, record time, effective instant, decision time, validity window, expiry event, data period and correction time are distinguished, with RFC 3339 and explicit offset mandated and the missing-offset case rejected rather than assumed. Straddling reads and in-flight supersession are asked about explicitly." }, { "dimension": "provenance", "status": "covered", "notes": "System of record, capture origin distinguishing native from imported records, canonicalisation before hashing, accountable steward per assertion, and append-only correction events. Integrity manifests are serial and never replaced in place." }, { "dimension": "ownership", "status": "covered", "notes": "The grantor is the default steward; the Dimension may not create permission beyond recorded delegation. Authority basis and its verification are modelled here while title itself is deferred to the ownership sibling, which is a required composition target." }, { "dimension": "validation", "status": "covered", "notes": "Consent validity elements are assessed element by element with an explicit asserted-versus-evidenced distinction; instrument validity is assessed against a jurisdiction profile's mandatory element set; unevaluable is distinguished from unsatisfied at the decision surface." }, { "dimension": "access", "status": "covered", "notes": "Deny by default across bundle, layer, finding and artefact scopes, named projections per role, enumerated exceptions including break-glass and supervisory access, and audit requirements for every decision and every read of the instrument itself." }, { "dimension": "retention and deletion", "status": "covered", "notes": "A versioned retention schedule per record class, minimisation and redaction rules, the erasure-versus-demonstrability tension surfaced as an explicit question, tombstones retained after destruction, and legal hold as a declared access exception." }, { "dimension": "interoperability", "status": "covered", "notes": "A versioned crosswalk artefact with per-row fidelity and loss, explicit refusal to assert conformance by default, extension terms marked non-interoperable, and unrecognised extensions treated as unevaluable rather than satisfied." }, { "dimension": "purpose limitation", "status": "covered", "notes": "Purpose is modelled as both text and coded terms with granularity and per-purpose acceptance, and compatibility assessment factors are elicited before a further use is permitted. Grounded in GDPR Art 5(1)(b) and 6(4), EDPB granularity guidance and DUO purpose codes." }, { "dimension": "evidence and proof", "status": "covered", "notes": "Notice snapshot, consent record with proof, receipt with checkable status, obligation discharge evidence and integrity manifests are all distinct artefacts with distinct identity strategies, so demonstrability does not depend on the storage system being trusted." }, { "dimension": "revocation propagation", "status": "covered", "notes": "Recipient notification with deadlines, cutoff and deletion acknowledgement, impossibility justification and irreversible-derivative handling are modelled as one finding with an append-only ledger, grounded in GDPR Art 19 and 17(2) and DGA Art 12." }, { "dimension": "conflict resolution", "status": "covered", "notes": "A declared combining strategy and precedence order, published as a versioned artefact whose version is recorded on every decision, reconciling the ODRL conflict property with XACML combining algorithms rather than assuming they agree." }, { "dimension": "authority and capacity", "status": "covered", "notes": "Capacity codes, representative documentation, verification outcome and the effect of a lapsed basis are modelled, with age thresholds parameterised per jurisdiction rather than fixed." }, { "dimension": "measurement", "status": "covered", "notes": "Quantitative constraints — read counts, periods, volumes — are modelled as constraint operands with units and reset periods, following the ODRL count and elapsedTime left operands." }, { "dimension": "security", "status": "gap", "notes": "Minimum authentication assurance for the grantee is captured as a data element and the decision surface is specified, but key management, token binding, replay resistance and the cryptographic suite for proofs are deliberately out of scope and are not supported by a primary source within this model. Treat as a gap to be closed by a security sibling model." }, { "dimension": "spatial", "status": "covered", "notes": "Spatial constraints on where a read may occur, permitted and prohibited territories, cross-border transfer safeguards and per-jurisdiction profiles are modelled; the specific safeguard instruments themselves are referenced, not defined." }, { "dimension": "pricing and compensation", "status": "not-applicable", "notes": "ODRL supports compensation duties and licensing terms, but this mixin is scoped to permission to read. Monetary terms would need a separate commercial-terms model and are declared out of scope rather than partially modelled." }, { "dimension": "collective and group consent", "status": "gap", "notes": "Every primary source examined models consent as an individual act by or for one data subject. Group, community or Indigenous collective permission has no support in the sources consulted and is recorded as an unmodelled gap rather than approximated by the delegate capacity." } ], "known_omissions": [ "Write, modify, delete and derivative-creation permissions: the mixin is scoped to read/disclosure, so a host needing write permission must compose a separate model.", "Compensation, royalties and licensing terms, which ODRL supports but which are excluded here as commercial rather than access semantics.", "Cryptographic protocol detail: key management, token binding, proof suites and replay resistance are referenced as alignments but not modelled.", "Machine-readable representation of non-consent legal bases, particularly legitimate-interest balancing tests, which are referenced but not structured.", "Consent specific to automated decision-making and profiling, which has distinct informational requirements not separately modelled.", "Sector and regional regimes not examined: ePrivacy and cookie consent, PSD2, CCPA/CPRA opt-out signals including Global Privacy Control, LGPD, PIPL, and the consent-manager architecture of India's DPDP Act.", "Collective or community-level permission and Indigenous data governance principles, for which no supporting primary source was found in this research.", "Machine-to-machine delegation chains of arbitrary depth: sub-delegation is asked about, but the transitive closure of delegated grants is not modelled.", "Quantitative assurance of receipt delivery, such as non-repudiation of delivery to the grantor.", "Full ISO 27560 and 29184 clause text is paywalled; field inventory is grounded in ISO catalogue pages plus the DPVCG mapping, not a line-by-line annex transcription.", "EDPB Guidelines 05/2020 on consent were not fetched; qualitative tests use GDPR recitals and articles only.", "ePrivacy/cookie-specific consent, CPRA 'share' opt-out, and LGPD/APPI/PIPL overlays are not modelled beyond jurisdiction and alignment hooks.", "IHE BPPC and HL7 CDA ConsentDirective are mentioned by FHIR as sources but not opened.", "GA4GH DUO and dynamic-consent platforms for research are discovered as likely omissions, not primary-encoded.", "ISO 27560 Annex F preference signals (including GPC) lack implementable primary detail here and are flagged not to be auto-promoted to consent.", "Joint-controller, processor-chain and sub-processor grant graphs are only present as named_recipients, not as a full multi-party topology.", "Death, incapacity and corporate succession have no single primary encoding.", "Machine/AI agents as grantees are supported only insofar as ODRL Party and UMA client allow non-human parties; no primary standard defines AI-specific consent." ], "conflicts": [ "ODRL leaves conflict resolution to a declared strategy property with values favouring permission, prohibition or invalidity, while XACML fixes outcomes through combining algorithms such as deny-overrides. The two are not equivalent, so this model requires the strategy to be declared and versioned rather than inherited from either.", "GDPR Art 7(3) states that withdrawal does not affect the lawfulness of processing before it, while product expectations and some erasure claims assume retroactive invalidation. The model adopts non-retroactivity as the default and requires any retroactive effect to be stated with its basis.", "45 CFR 164.508 permits conditioning research-related treatment on an authorization and permits an expiration of 'none' for research, whereas GDPR Art 7(4) treats conditioning with suspicion and EDPB guidance discourages open-ended consent. Instrument form must therefore be a jurisdiction parameter, not a constant.", "DPV's consent status vocabulary (given, refused, withdrawn, expired, revoked, invalidated, unknown) and FHIR Consent.status (draft, active, inactive, entered-in-error) are not isomorphic; a value in one cannot be mapped losslessly to the other, so crosswalk rows carry an explicit fidelity rating.", "ISO/IEC TS 27560:2023 is a Technical Specification rather than a full International Standard, and its normative text is paywalled; field-level grounding here comes from the DPVCG mapping guide. Conformance claims against it are therefore weaker than the citation might suggest.", "Kantara Consent Receipt v1.1 predates ISO/IEC TS 27560 and its field set does not align one-to-one with it; a system emitting both must reconcile them explicitly.", "The previous-version material asserted that no contract is active without captured consent. That is contradicted by GDPR Art 6, which recognises bases other than consent, and by court-ordered or statutory access. This model treats consent as one basis among several and records the conflict.", "Kantara Consent Receipt 1.1 is narrated as principal-to-controller; ISO/IEC TS 27560 receipt is organisation-to-principal.", "ODRL Agreement can have a legal-person assigner; GDPR consent cannot.", "FHIR grantee (must comply) is not identical to ODRL assignee (receives permission).", "FHIR status vocabulary has no withdrawn code; DPV and GDPR treat withdrawal as first-class.", "ODRL conflict strategy perm can prefer a Permission over a Prohibition, which collides with privacy fail-closed defaults.", "ISO 27560 lawful_basis is optional on a consent record; GDPR always needs a basis.", "UMA refresh must not re-assess authorization, so token lifetime can outrun a withdrawn grant unless explicitly revoked.", "Kantara CR 1.1 field vocabulary is documented as not GDPR-aligned field-for-field.", "FHIR Consent.action missing means all actions, while this catalogue's purpose is permission to read." ], "regional_assumptions": [ "Primary legal grounding is the European Union: GDPR as interpreted by the EDPB, plus the Data Governance Act for intermediation and portable consent forms.", "The single non-EU regime examined in depth is the US health sector under 45 CFR 164.508, used deliberately as a counterexample to test whether 'consent' generalises. It does not, which is why instrument form is parameterised.", "The age at which a person may grant for themselves is assumed to lie in the range set by GDPR Art 8 (16, reducible by Member State law to not below 13); individual Member State thresholds are not enumerated and must be supplied by the jurisdiction profile.", "ISO 639 language tags, RFC 3339 timestamps and resolvable IRIs are assumed available in every adopting Dimension; systems that cannot supply an explicit UTC offset will fail validation rather than degrade silently.", "Cross-border transfer conditions are referenced generically; the specific safeguard instruments valid in any given corridor are not enumerated and are deferred to the jurisdiction profile.", "Sector regimes with their own consent architectures — telecommunications, financial services, genomics beyond DUO — are assumed to map onto the parameterised profile, which is untested.", "Privacy-flavour quality tests are written against GDPR as the densest primary privacy-consent statute; other regimes must be added as profiles.", "Article 8 age of consent is a Member State value between 13 and 16; no single number is universal.", "GDPR does not apply to deceased persons or to legal persons; those grants are usage-licence or local-law profiles.", "ISO 27560 is a Technical Specification, not an IS; a revision (CD 27560.2) is in progress and may change mandatory fields.", "FHIR Consent is Trial Use maturity 2; only the privacy use is fully modelled." ], "adversarial_checks": [ "Tested whether consent is a necessary precondition for a grant, as the previous version asserted. GDPR Art 6 recognises contract, legal obligation, vital interests, public task and legitimate interests alongside consent, and HIPAA permits many disclosures without authorization. The claim was rejected: consent became an optional, evidenced basis rather than a mandatory gate.", "Tested whether 'consent' generalises across regimes by comparing GDPR Art 4(11) and Art 7 against 45 CFR 164.508. The core elements differ materially — HIPAA requires an expiration date or event, a redisclosure warning and a conditioning statement, and permits an expiration of 'none' for research. The model therefore carries an instrument-form discriminator driven by a jurisdiction profile, rather than assuming a single consent shape.", "Tested whether revocation should invalidate prior reads. GDPR Art 7(3) preserves the lawfulness of pre-withdrawal processing and 164.508(b)(5) provides a reliance exception. The intuitive 'revocation undoes everything' default was rejected in favour of forward-only effect with an explicit reliance record.", "Tested whether an ODRL profile alone could serve as the whole model. ODRL supplies parties, targets, actions, constraints and duties, but has no consent evidence, no capacity or authority verification, no state machine for an Agreement and no receipt concept. The reduction was rejected; ODRL is retained as an alignment only.", "Tested whether the disclosure shape belongs here, since FHIR provision.securityLabel and ODRL constraints make it tempting to inline. Doing so would duplicate the projection sibling and create two masters for the same rule, so scope clauses reference a projection policy identifier and define no shape.", "Tested whether a consent timestamp could serve as a record identifier, as some receipt implementations imply. Two acts by the same subject in the same second would collide, and timestamps are subject to correction; 27560 as rendered by the DPVCG guide recommends a distinct UUID. The date-as-identifier pattern was rejected explicitly in the artefact rules.", "Tested whether a single 'is this covered' boolean suffices at the decision surface. XACML shows four outcomes are needed because an evaluation error is not a denial, and obligations must travel with a permit. A boolean was rejected in favour of an outcome vocabulary plus obligations, with unevaluable cases required to alert rather than silently deny.", "Searched for support for collective or group consent to test the assumption that one grantor equals one instrument. No primary source among those consulted models it, so it is recorded as a gap rather than approximated through the delegate capacity, which would misrepresent it.", "False permit: evaluating an ODRL Offer, a FHIR draft, or a Kantara receipt as if it were an active Agreement.", "False permit: legal-person or public-authority 'consent' under power imbalance, or contract bundling of unnecessary processing.", "False permit: child indication without parental capacity where Article 8 applies, or stale guardian after the child crosses the threshold.", "False permit: purpose creep via Recital 50 compatibility language on a consent-based grant.", "False permit: UMA refresh or cached validity token used after withdrawal because assessment is not re-run.", "False deny: treating default-deny so naively that emergency or legal-obligation reads cannot be distinguished (those belong to other bases, not to this mixin).", "Conformance theatre: asserting ISO 27560 or GDPR compliance because a JSON receipt exists, without indication evidence, unbundling or an integrity-protected master record.", "Identifier collision: using consentTimestamp, FHIR date, or receipt id as the instrument primary key, splitting revocation.", "Scope inflation: missing data_meaning treated as all data, or missing FHIR action treated as all actions, against this model's read-only purpose.", "Propagation gap: status=withdrawn on the master while downstream processors still hold live RPTs." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both providers independently derived mixin for vr.wm-xct-002 and agree on the same core split: the instrument owns parties, scope selection, purpose, action, constraints, duties, consent evidence, lifecycle and the decision surface, while title/delegation, disclosure shape, the audit log of exercises, enforcement casework and identity proofing are sibling models referenced by identifier. The instrument is a first-class record (ODRL Policy, FHIR Consent, TS 27560 consent record) but is never standalone in this catalogue: it attaches to any host entry whose data may cross an ownership or accountability boundary, which is exactly the mixin contract. No split, reclassification or merge is warranted." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude adopted as base", "rationale": "Claude's boundary is the more complete partition: seven sourced neighbour distinctions, an explicit owns/does-not-own scope statement, and dedicated layers for the decision surface, conflict precedence, assurance and stewardship, and jurisdictional variance with no orphaned content. It also resolves the hardest boundary question correctly and adversarially — consent is one possible basis of a grant, not a mandatory gate — which Grok only partially accommodates by pushing non-consent bases out of scope. Source count was not decisive." }, { "concept": "Entry kind", "disposition": "Accepted as mixin, unchanged", "rationale": "Independent agreement between both providers on mixin, with the same underlying reasoning that the instrument is a first-class record that nonetheless attaches to a host entry rather than standing alone. No evidence in either pack supports reclassification or a split." }, { "concept": "Instrument identity and mastering", "disposition": "Accepted from Grok into provenance-integrity", "rationale": "Base claimed identity coverage in prose but shipped no finding that owns the canonical identifier, scheme, mastering system, schema version or the master-versus-copy-versus-receipt distinction. Evidence-backed in ODRL, TS 27560 and FHIR, and it closes the identifier-collision failure both packs flag." }, { "concept": "Party functional roles", "disposition": "Accepted from Grok into parties-and-authority", "rationale": "Subject-distinct-from-grantor, manager, controller/enforcer and requesting party are absent from the base, as is the FHIR-grantee versus ODRL-assignee non-identity. These determine who may act on the instrument and who evaluates reads against it, so their absence is a real hole rather than a stylistic difference." }, { "concept": "Stale entitlement after withdrawal", "disposition": "Accepted from Grok into termination-and-propagation, governance level only", "rationale": "Revocation that does not reach already-issued credentials is a live failure mode the base names in a question but never models. Imported as a duty and a propagation state, not as protocol mechanics, so the base out-of-scope rule on token, key and OAuth/UMA mechanics survives intact." }, { "concept": "Privacy-consent versus usage-licence flavour and legal-person grantor", "disposition": "Accepted from Grok into jurisdictional-variance", "rationale": "The base never classifies instrument flavour and is entirely silent on non-natural-person grantors, while GDPR bars legal-person consent and ODRL permits legal-person assigners. That is a hard, evidence-backed constraint that changes which mandatory elements and lawfulness tests apply." }, { "concept": "Conflict evaluation as a function", "disposition": "Accepted from Grok as a new function", "rationale": "The base conflict-precedence layer had no operating function; folding conflict handling into evaluate-coverage hides the declared combining strategy and omits action-inheritance clashes. Added as a distinct function rather than merged." }, { "concept": "Notice content and informedness controls (ISO/IEC 29184)", "disposition": "Rejected — breaches base boundary", "rationale": "The base deliberately assigns notice text, layering and presentation to the transparency sibling and retains only the exact notice version plus an immutable evidence snapshot. Importing Grok's notice-content finding would create a second master for the same rule. ISO/IEC 29184:2020 is retained as a deferred source for informedness testing, not as structure." }, { "concept": "Acting capacity and Article 8 age thresholds", "disposition": "Rejected as duplicative", "rationale": "Base grantor-authority-basis already carries capacity codes, representative documentation, verification outcome and the effect of a lapsed basis, and jurisdictional-parameters already parameterises the age threshold rather than fixing it. The counselling-service carve-out under Recital 38 is routed to the jurisdiction profile rather than minted as a new finding." }, { "concept": "Status and activation path", "disposition": "Rejected as duplicative", "rationale": "Base contract-state-model already enumerates the state set and legal transitions, separates proposed from accepted-and-active, handles suspension short of termination, and resolves store-versus-token disagreement. Grok's activation-path nuance is already carried by the activate-grant function." }, { "concept": "Deontic rule tri-partition (Permission, Prohibition, Duty)", "disposition": "Rejected as duplicative; inheritance nuance deferred", "rationale": "Permitted and prohibited action terms, pre-condition duties and duty consequences are already split across permitted-action-read-semantics and obligations-and-duties in the base. Only the ODRL includedIn/implies action-inheritance mechanism is genuinely new, and it is too narrow to justify a finding that would re-import three base findings; it is deferred for grounding in the ODRL vocabulary instead." }, { "concept": "Target objects and FHIR data.meaning", "disposition": "Rejected as duplicative", "rationale": "Base scope-clause-selection already covers selector kind, snapshot-versus-live resolution, data period and the specificity floor, and fail-closed-handling already denies rather than expanding on a missing attribute, which is the guard against the missing-data-means-all-data default." }, { "concept": "Consent record versus consent receipt", "disposition": "Rejected as duplicative", "rationale": "Base splits this into consent-record-and-proof and receipt-and-portability with separate artefacts, identity strategies, proof and status-checkability. The Kantara-versus-27560 direction divergence is already recorded as a conflict by both providers and needs no new structure." }, { "concept": "Mapping conflict register", "disposition": "Rejected as structure; absorbed as recorded conflicts", "rationale": "Base standards-alignment-map already owns a versioned crosswalk with per-row fidelity, loss direction and refusal to assert conformance by default. Grok's eight enumerated conflicts are retained as model conflict entries so no evidence is lost, but they do not warrant a competing finding." }, { "concept": "Completeness-versus-legal-validity quality flags", "disposition": "Rejected as duplicative", "rationale": "The base already separates asserted from evidenced validity elements, distinguishes unevaluable from unsatisfied at the decision surface, and denies by default, which together carry Grok's rule that a complete record must never be read as a permit." }, { "concept": "Grantor succession (death, incapacity, corporate merger)", "disposition": "Deferred, not added", "rationale": "Genuinely missing from the base, but Grok itself records that death, incapacity and corporate succession have no single primary encoding and that GDPR Recital 27 leaves deceased persons to Member State law. Adding the wholesale finding would also re-import withdrawal, expiry and supersession that the base already models. Routed to deferred research for jurisdiction-profile grounding." } ], "publicationHolds": [ "Source liveness and version pinning is unverified for all nineteen accepted sources. Two specific reconciliations are mandatory before publication: pin FHIR Consent to the version-qualified R5 URL rather than the unversioned current URL that will drift, and reconcile the two DPVCG 27560-guide citations that disagree on both host and date (w3c-cg.github.io retrieved 2026-08-23 versus w3id.org Final Community Group Report 15 February 2026).", "Domain-profile validation is incomplete. The model has been exercised only against EU/GDPR, the US health sector under 45 CFR 164.508, and a healthcare FHIR profile. At least one non-health, non-EU jurisdiction profile must be run end to end before publication to test whether the instrument-form and flavour parameters actually generalise.", "Normative text for ISO/IEC TS 27560:2023 and ISO/IEC 29184:2020 is paywalled; field inventories rest on catalogue pages plus the DPVCG mapping rather than annex text. TS 27560 is a Technical Specification, not an International Standard, and a revision (CD 27560.2) may change mandatory fields. Any field-level claim must be labelled as mapping-derived.", "The security dimension is self-declared a gap by the base (key management, token binding, replay resistance, cryptographic proof suites). Now that entitlement cutoff is imported, publication must name the sibling security model that owns these and state plainly that this model does not close them.", "Collective, community and Indigenous group permission is unsupported by any source in either pack and must be published as an explicitly unmodelled gap, never approximated through the delegate capacity." ], "deferredResearch": [ "Grantor succession: death, loss of capacity, corporate merger, joint-controller arrangements and restoration after accidental withdrawal. GDPR Recital 27 leaves deceased persons to Member State law and no consulted source supplies a primary encoding; needs jurisdiction-profile research before any structure is minted.", "Preference signals under ISO/IEC TS 27560 Annex F, including Global Privacy Control and CPRA-style opt-out signals. The base lists these as unexamined omissions and Grok flags promoting them to consent as an unproven alignment; research must settle whether they are ever a valid control input.", "ODRL action inheritance via includedIn and implies, and the inherited permission/prohibition conflicts it produces within a single instrument. Needs grounding in the ODRL Vocabulary before folding into the conflict-precedence layer and the newly added conflict-evaluation function.", "Informedness testing sources are split across providers: only the base fetched EDPB Guidelines 05/2020 and only Grok cited ISO/IEC 29184:2020. Reconcile both against the transparency sibling boundary so notice-content controls are tested without duplicating the notice model.", "Regimes not examined by either provider: ePrivacy and cookie consent, LGPD, PIPL, APPI, and the consent-manager architecture of India's DPDP Act, each of which may change the instrument form rather than merely its parameters.", "Machine and AI agents as grantees, and multi-hop delegation chains of arbitrary depth. Sub-delegation is asked about in the base but the transitive closure of delegated grants has no primary encoding in either pack." ] }, "statistics": { "sources": 19, "bundles": 6, "layers": 16, "findings": 29, "questions": 113, "artifacts": 24, "functions": 13 } }