{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.wm-xct-002","code":"wm-xct-002-access-contract-consent","url":"https://ver.cy/models/wm-xct-002-access-contract-consent/","name":"Access Contract / Consent","alternateNames":["S2"],"kind":"world-model","status":"published","version":"0.3.0-research.1","language":"en","classifiers":{"family":"World Models","category":"Cross-cutting context","entryKind":"mixin","plane":"","domain":["XCT.ACC"],"industry":["Cross-industry"],"navPath":"NAV.XCT.ACC","tags":["access","contract","consent","xct.acc"],"facets":{}},"whatItIs":"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.","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":{"in":["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":["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"],"boundaries":[{"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."},{"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."},{"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."},{"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."},{"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."},{"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."},{"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."}]},"distinguishingFeatures":["An access instrument grants a defined use for a purpose on a lawful basis, which may be consent, contract, law or court order.","It differs from ownership (WM-XCT-001), which determines who can grant, and from the disclosure shape (WM-XCT-003) of what leaves.","Enforcement and audit are separate models; the instrument only states coverage.","Termination ends coverage forward and does not erase past lawful reads."],"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.","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.","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.","questions":[{"text":"Which authoritative identifier designates the grantor, and in which master system is it resolved?","id":"q-grantor-identifier","kind":"identity"},{"text":"In what capacity does the grantor act — data subject, owner, personal representative, guardian, or delegate?","id":"q-grantor-capacity","kind":"authority"},{"text":"What evidence documents the representative's authority, and when was it last verified?","id":"q-authority-evidence","kind":"evidence"},{"text":"What happens to an active grant if the authority basis lapses or is later found invalid?","id":"q-authority-lapse","kind":"exception"}]},{"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.","questions":[{"text":"Is the grantee an individually named party, a party collection, or a bearer of a transferable ticket?","id":"q-grantee-kind","kind":"classification"},{"text":"Which onward recipients or sub-processors are within the grant, and under which flow-down duties?","id":"q-onward-recipients","kind":"relationship"},{"text":"How is the grantee authenticated at read time, and at what assurance level?","id":"q-grantee-authn","kind":"security"},{"text":"May the grantee sub-delegate its read right, and what record must exist if it does?","id":"q-subdelegation","kind":"authority"}]},{"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.","questions":[{"text":"Who is the grantor, and which ownership, parental-responsibility or delegation record authorises them to grant?","id":"party-functional-roles-q01","kind":"authority"},{"text":"Which party or party collection is the grantee, and are members refined by attributes such as role or age?","id":"party-functional-roles-q02","kind":"access"},{"text":"Is the data subject a different person from the grantor, as with a parent granting over a child's record?","id":"party-functional-roles-q03","kind":"relationship"},{"text":"Which actor manages the instrument through its lifecycle and which actor evaluates reads against it?","id":"party-functional-roles-q04","kind":"ownership"}]}]},{"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.","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.","questions":[{"text":"How is the covered set designated: enumerated identifiers, category codes, or an evaluable selector expression?","id":"q-selector-kind","kind":"composition"},{"text":"Is the covered set resolved as a snapshot at activation or re-evaluated live at each read?","id":"q-resolution-mode","kind":"state"},{"text":"Which creation or observation window of the covered objects falls inside the grant?","id":"q-data-period","kind":"temporal"},{"text":"What is the specificity floor below which a scope clause must be rejected as too broad to be meaningful?","id":"q-specificity-floor","kind":"constraint"}]},{"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.","questions":[{"text":"Which data categories are covered, expressed in which governed vocabulary and version?","id":"q-data-categories","kind":"classification"},{"text":"Does the scope include special-category or sensitive data that requires explicit consent or a separate instrument?","id":"q-special-category","kind":"requirement"},{"text":"Which categories are explicitly excluded by carve-out, and how is the exclusion enforced at read time?","id":"q-carve-outs","kind":"constraint"},{"text":"Which security labels or handling caveats travel with the covered data once disclosed?","id":"q-security-labels","kind":"security"}]}]},{"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.","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.","questions":[{"text":"What is the declared purpose, and which coded purpose terms express it?","id":"q-purpose-terms","kind":"definition"},{"text":"Is a proposed use inside the declared purpose, or does it require a new grant?","id":"q-purpose-compatibility","kind":"decision"},{"text":"How granular must purposes be when several are offered in one instrument?","id":"q-purpose-granularity","kind":"requirement"},{"text":"How is a later narrowing or widening of the declared purpose detected and handled?","id":"q-purpose-drift","kind":"lifecycle"}]},{"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.","questions":[{"text":"Which action terms are permitted and which are explicitly prohibited under this instrument?","id":"q-action-terms","kind":"classification"},{"text":"Does a permitted read include caching, indexing, derivation or aggregation of the disclosed data?","id":"q-read-includes","kind":"definition"},{"text":"Is one decision valid for a single read, a session, or a standing entitlement?","id":"q-exercise-unit","kind":"state"},{"text":"Which actions beyond read fall outside this mixin and must be modelled elsewhere?","id":"q-out-of-scope-actions","kind":"interoperability"}]}]},{"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.","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.","questions":[{"text":"When does the grant enter into force and when does it end — a fixed instant, a defined event, or never?","id":"q-validity-window","kind":"temporal"},{"text":"Which quantitative limits apply, such as reads per period, total count or data volume?","id":"q-quantitative-limits","kind":"measurement"},{"text":"Which spatial or jurisdictional constraints restrict where the read may occur or where disclosed data may land?","id":"q-spatial-limits","kind":"spatial"},{"text":"What outcome applies when a constraint cannot be evaluated because an attribute is missing?","id":"q-unevaluable-constraint","kind":"exception"}]},{"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.","questions":[{"text":"Which duties attach to the grantee, and is each a pre-condition, a continuing duty, or a post-termination survival?","id":"q-duty-timing","kind":"requirement"},{"text":"What consequence applies if a duty is not discharged by its deadline?","id":"q-duty-consequence","kind":"exception"},{"text":"What evidence is required before a duty is treated as discharged?","id":"q-duty-evidence","kind":"evidence"},{"text":"Which duties survive revocation or expiry of the grant, and for how long?","id":"q-duty-survival","kind":"lifecycle"}]}]}]},{"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.","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.","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.","questions":[{"text":"Which affirmative act constituted the indication, and was any pre-ticked box, silence or inactivity relied on?","id":"q-affirmative-act","kind":"validation"},{"text":"Was the service or contract made conditional on consent that was not necessary to perform it?","id":"q-conditioning","kind":"constraint"},{"text":"Was explicit consent required, and by what mechanism was the heightened standard met?","id":"q-explicit-consent","kind":"requirement"},{"text":"Which validity elements are evidenced in the record and which are only asserted by the capturing system?","id":"q-asserted-vs-evidenced","kind":"evidence"}]},{"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.","questions":[{"text":"Through which channel and interface was the act captured, and what exact wording version was displayed?","id":"q-capture-channel","kind":"provenance"},{"text":"Which language and which jurisdiction applied at the moment of capture?","id":"q-capture-language","kind":"spatial"},{"text":"What was the event time of the act as against the time the record was ingested?","id":"q-act-vs-record-time","kind":"temporal"},{"text":"Is the referenced notice version immutably retrievable for the life of the record?","id":"q-notice-retrievability","kind":"quality"}]}]},{"id":"consent-evidence","name":"Consent Evidence and Receipt","description":"The durable record that supports demonstrability and the portable copy given back to the grantor.","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.","questions":[{"text":"Which record structure and schema version is used to demonstrate the act?","id":"q-record-schema","kind":"interoperability"},{"text":"What proof binds the record to the grantor's act, and who can verify it independently?","id":"q-record-proof","kind":"evidence"},{"text":"Is the record tamper-evident, and how is its integrity re-checked over time?","id":"q-record-integrity","kind":"quality"},{"text":"What minimum record must survive after the covered data itself is deleted?","id":"q-minimum-survivor","kind":"retention"}]},{"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.","questions":[{"text":"What must the receipt contain for the grantor to understand and act on what they agreed?","id":"q-receipt-content","kind":"definition"},{"text":"Through which channel is the receipt delivered, and how is it re-obtained later?","id":"q-receipt-delivery","kind":"process"},{"text":"Can a third party verify the receipt without contacting the issuer, and how is its current status checked?","id":"q-receipt-verification","kind":"validation"},{"text":"Is the receipt machine-readable enough to drive withdrawal in a system other than the issuer's?","id":"q-receipt-machine-readable","kind":"interoperability"}]}]}]},{"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.","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.","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.","questions":[{"text":"What is the enumerated state set, and which transitions between states are legal?","id":"q-state-set","kind":"state"},{"text":"Which state is authoritative when the record store and a previously issued token disagree?","id":"q-authoritative-state","kind":"decision"},{"text":"Can an instrument be suspended without being terminated, and what does suspension permit?","id":"q-suspension","kind":"lifecycle"},{"text":"How is a proposed or requested instrument distinguished from an accepted and active one?","id":"q-proposed-vs-active","kind":"classification"}]},{"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.","questions":[{"text":"Which timestamps are mandatory on every instrument and every consent event?","id":"q-mandatory-times","kind":"temporal"},{"text":"Is a time without an explicit offset ever acceptable, and what is the fallback if one is received?","id":"q-missing-offset","kind":"constraint"},{"text":"How is a correction to a recorded time captured without rewriting history?","id":"q-retroactive-correction","kind":"provenance"},{"text":"Which time governs a read that begins before expiry and completes after it?","id":"q-straddling-read","kind":"exception"}]}]},{"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.","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.","questions":[{"text":"Which changes may be applied in place and which require a new consent act?","id":"q-inplace-vs-reconsent","kind":"decision"},{"text":"How are versions identified, ordered, and linked to the version they supersede?","id":"q-version-identity","kind":"identity"},{"text":"From which instant does a superseding version govern, and what governs reads already in flight?","id":"q-supersession-instant","kind":"temporal"},{"text":"Is there an interval after which the instrument must be refreshed or re-confirmed?","id":"q-refresh-interval","kind":"lifecycle"}]}]},{"id":"termination-and-propagation","name":"Termination and Propagation","description":"Ending a grant early and making that ending real for everyone downstream.","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.","questions":[{"text":"Who may issue a withdrawal or revocation, and through which channels must it be possible?","id":"q-who-may-revoke","kind":"authority"},{"text":"From which instant does termination take effect, and are prior reads thereby invalidated?","id":"q-termination-instant","kind":"temporal"},{"text":"Which processing may lawfully continue after withdrawal, and on what stated basis?","id":"q-post-withdrawal-processing","kind":"exception"},{"text":"What confirmation is returned to the grantor that the withdrawal took effect?","id":"q-withdrawal-confirmation","kind":"evidence"}]},{"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.","questions":[{"text":"Which recipients must be notified of termination, and within what deadline?","id":"q-who-to-notify","kind":"process"},{"text":"What counts as acceptable proof that a recipient stopped reading and deleted its copies?","id":"q-cutoff-proof","kind":"evidence"},{"text":"What is done when notification is impossible or would involve disproportionate effort?","id":"q-notification-impossible","kind":"exception"},{"text":"How are irreversible derivatives such as trained models, aggregates and publications handled?","id":"q-derivatives","kind":"constraint"}]},{"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.","questions":[{"text":"Is there a current entitlement token, of which kind, expiring when, and is it unique to this requesting party and client?","id":"entitlement-cutoff-q01","kind":"security"},{"text":"Which parties currently hold copies or caches under this grant, and which have confirmed cutoff?","id":"entitlement-cutoff-q02","kind":"process"},{"text":"Were RPTs, refresh tokens and persisted-claims tokens revoked, at what time, and did refresh continue to mint access without re-assessment?","id":"entitlement-cutoff-q03","kind":"security"}]}]}]},{"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.","layers":[{"id":"coverage-decision","name":"Coverage Decision","description":"The request, the outcome vocabulary, the returned obligations and the handling of unevaluable cases.","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.","questions":[{"text":"Which attributes must the requester supply before a decision can be evaluated at all?","id":"q-decision-inputs","kind":"process"},{"text":"Which decision values may be returned, and what must the enforcing party do for each?","id":"q-decision-values","kind":"decision"},{"text":"What may be returned alongside the outcome — obligations, scope fingerprint, expiry — without disclosing contract content?","id":"q-decision-payload","kind":"privacy"},{"text":"How long may a decision be cached and relied upon before re-evaluation?","id":"q-decision-reliance","kind":"temporal"}]},{"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.","questions":[{"text":"Is the default outcome denial, and under which narrow, declared conditions may any fallback permit apply?","id":"q-default-outcome","kind":"constraint"},{"text":"How is an unevaluable constraint distinguished from one that was evaluated and not satisfied?","id":"q-unsatisfied-vs-unevaluable","kind":"validation"},{"text":"What diagnostic detail may be returned to the requester without leaking contract content?","id":"q-diagnostic-leakage","kind":"privacy"},{"text":"Which unevaluable outcomes must raise an operational alert rather than resolve to a silent denial?","id":"q-alerting","kind":"exception"}]}]},{"id":"conflict-precedence","name":"Conflict and Precedence","description":"How several applicable instruments, prohibitions and overriding duties are combined into one defensible outcome.","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.","questions":[{"text":"Which combining strategy applies when one instrument permits and another prohibits the same read?","id":"q-combining-strategy","kind":"decision"},{"text":"Does a narrower or later instrument automatically supersede a broader or earlier one?","id":"q-narrower-later","kind":"constraint"},{"text":"How is a conflict between the instrument and an overriding legal duty recorded and surfaced?","id":"q-legal-override","kind":"exception"},{"text":"Is the combining strategy declared on the instrument or fixed by the adopting Dimension?","id":"q-strategy-authority","kind":"authority"}]}]}]},{"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.","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.","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.","questions":[{"text":"Which system of record is authoritative for this instrument, and what is its identifier there?","id":"q-system-of-record","kind":"provenance"},{"text":"How is the record canonicalised before it is hashed or signed?","id":"q-canonicalisation","kind":"quality"},{"text":"Who is accountable for the correctness of each recorded assertion?","id":"q-accountability","kind":"ownership"},{"text":"How are imported or migrated records distinguished from natively captured ones?","id":"q-import-provenance","kind":"classification"}]},{"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.","questions":[{"text":"What is the canonical identifier of this access contract, in which scheme, and which mastering system assigned it?","id":"instrument-identity-q01","kind":"identity"},{"text":"Which information-model profile and schema version interpret the terms of this instrument?","id":"instrument-identity-q02","kind":"interoperability"},{"text":"Is this instance the master record, a FHIR copy identifier, or a receipt that only references the record?","id":"instrument-identity-q03","kind":"provenance"}]}]},{"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.","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.","questions":[{"text":"How long must the instrument and its consent evidence be retained after termination, and on what stated basis?","id":"q-retention-period","kind":"retention"},{"text":"Which fields must be minimised or redacted while keeping the record capable of demonstrating the act?","id":"q-minimisation","kind":"privacy"},{"text":"Does an erasure request from the grantor extinguish the consent evidence itself?","id":"q-erasure-vs-evidence","kind":"exception"},{"text":"What is deleted, what is anonymised, and what remains as a tombstone after the retention period?","id":"q-tombstone","kind":"decision"}]}]},{"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.","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.","questions":[{"text":"Who may read the full instrument, and who may receive only a validity token?","id":"q-who-reads-contract","kind":"access"},{"text":"Which named projection does each role receive, and what does each omit?","id":"q-projection-per-role","kind":"access"},{"text":"May a grantee learn the identity of other grantees or the existence of other grants over the same objects?","id":"q-cross-grantee-visibility","kind":"privacy"},{"text":"How is supervisory or regulator access authorised, bounded and logged?","id":"q-regulator-access","kind":"authority"}]}]}]},{"id":"interoperability","name":"Interoperability and Jurisdiction","description":"Declared, evidence-backed mappings to external standards, and the parameters that change with the governing legal regime.","layers":[{"id":"standards-alignment","name":"Standards Alignment","description":"Crosswalks to external vocabularies with explicit statements of fidelity and loss.","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.","questions":[{"text":"To which external standard concept does each core element map, and at what fidelity?","id":"q-mapping-fidelity","kind":"interoperability"},{"text":"Which mappings are lossy, and precisely what is lost in each direction?","id":"q-mapping-loss","kind":"quality"},{"text":"Is a conformance claim asserted against any target standard, and what evidence supports it?","id":"q-conformance-claim","kind":"evidence"},{"text":"What is the fallback when a target standard has no equivalent concept for a required element?","id":"q-no-equivalent","kind":"exception"}]}]},{"id":"jurisdictional-variance","name":"Jurisdictional Variance","description":"The parameters that must be supplied per legal regime before the instrument can be validated at all.","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.","questions":[{"text":"Which law governs this instrument, and which supervisory authority is competent over it?","id":"q-governing-law","kind":"authority"},{"text":"In this jurisdiction, is the correct instrument a consent, an authorization, or another form with different mandatory elements?","id":"q-instrument-form","kind":"classification"},{"text":"What is the age at which a person may grant for themselves in this jurisdiction, and how is a lower age handled?","id":"q-age-threshold","kind":"constraint"},{"text":"Which cross-border transfer conditions attach to a read performed outside the originating jurisdiction?","id":"q-transfer-conditions","kind":"spatial"}]},{"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.","questions":[{"text":"Is this instrument an Offer, an Agreement already granted, a FHIR draft, or a mere Set of rules?","id":"instrument-flavour-classification-q01","kind":"classification"},{"text":"Does this grant authorise processing of personal data on a consent legal basis, or only usage of a non-personal asset?","id":"instrument-flavour-classification-q02","kind":"classification"},{"text":"If a requested read matches no provision, is the default permit, deny, or invalid-by-conflict?","id":"instrument-flavour-classification-q03","kind":"decision"}]}]}]}]},"agentConduct":{"may":["Evaluate whether a proposed read is covered by an in-force instrument.","Capture a consent act with its notice version and channel.","Issue a receipt to the grantor.","Propagate a withdrawal to downstream holders."],"mustNot":["Permit access when coverage cannot be established.","Treat a stored receipt as valid consent without quality checks.","Bundle consent for unrelated purposes or make withdrawal harder than granting.","Extend a grant to a new purpose or recipient without a new instrument.","Pre-tick, nudge or pressure a person into consenting."],"requiresHuman":["Granting consent on a person's behalf.","Approving an instrument based on statute or court order.","Resolving conflicts between instruments."]},"ethics":{"considerations":["Consent must be free, informed and revocable; power imbalance can make it meaningless.","Complex terms exclude people with low literacy or disabilities from real choice.","Overbroad grants expose people to uses they never expected."],"affectedParties":["Grantors and data subjects","Recipients of access","Children and people represented by others"]},"owners":{"steward":"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.","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"]}],"masterSystems":[]},"relations":[{"target":"Any world-model entry whose data may cross an ownership or accountability boundary","type":"composes","note":"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."},{"target":"world.ownership — ownership, title and delegation model (legacy S1)","type":"references","note":"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."},{"target":"world.disclosureScope — disclosure shape and projection policy model (legacy S3)","type":"references","note":"Each scope clause points at a projection policy identifier that determines the shape in which covered objects leave; this model never describes shape itself."},{"target":"world.accessAudit — access audit model (legacy S4)","type":"references","note":"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."},{"target":"world.accessEnforcement — enforcement and violation model (legacy S7)","type":"references","note":"Undischarged duties and out-of-scope reads escalate into cases there; this model contributes the duty definition, its deadline and its discharge status."},{"target":"Generic contract primitive (parties, terms, formation, termination)","type":"extends","note":"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."},{"target":"ODRL Information Model 2.2 and ODRL Vocabulary & Expression 2.2","type":"aligned","note":"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."},{"target":"ISO/IEC TS 27560:2023 consent record information structure, as rendered by the DPVCG guide with DPV 2.1","type":"aligned","note":"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."},{"target":"HL7 FHIR R5 Consent resource","type":"aligned","note":"Map grantor, grantee, manager, controller, verification, decision and nested provisions for health-sector exchange; note the state vocabularies are not isomorphic with DPV."},{"target":"OASIS XACML 3.0","type":"aligned","note":"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."},{"target":"Kantara UMA 2.0 grant and IETF RFC 9396 authorization details","type":"aligned","note":"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."},{"target":"W3C Verifiable Credentials Data Model 2.0","type":"aligned","note":"Express the receipt as an independently verifiable credential with validFrom, validUntil, evidence, termsOfUse and a checkable credentialStatus supporting revocation and suspension."},{"target":"GA4GH / OBO Data Use Ontology (DUO)","type":"aligned","note":"Supply governed purpose codes and use modifiers for research data access, demonstrating that purposes and duties are coded reference data rather than free text."},{"target":"Privacy notice and transparency model","type":"references","note":"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."},{"target":"Purpose, data category and action vocabularies registry","type":"composes","note":"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."},{"target":"Ownership and delegation model (legacy S1, world.ownership)","type":"neighbor","note":"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."},{"target":"Disclosure scope / projection policy model (legacy S3)","type":"neighbor","note":"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."},{"target":"Access audit model (legacy S4)","type":"neighbor","note":"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."},{"target":"Access enforcement model (legacy S7)","type":"neighbor","note":"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."},{"target":"Legal-basis and lawfulness model","type":"neighbor","note":"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."},{"target":"Policy decision and enforcement infrastructure (XACML PDP/PEP, UMA authorization server)","type":"neighbor","note":"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."},{"target":"Privacy notice / transparency model","type":"neighbor","note":"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."}],"interaction":{"identity":{"applicability":"required","items":["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."]},"properties":{"applicability":"not-applicable","items":[]},"recognition":{"applicability":"optional","items":["An instrument names a grantor, a grantee, a scope, a purpose, a basis and a validity period.","Confused with a privacy notice, a terms-of-service acceptance, a role-based permission and a cookie banner choice."]},"capabilities":{"applicability":"required","items":["Verify grantor authority: 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.","Draft grant instrument: 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.","Capture consent act: 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.","Activate grant: Move a validated instrument into force from a stated instant, fixing the version that governs and publishing its validity for decision points.","Issue receipt to grantor: Produce and deliver the durable, portable copy of what was agreed, including the withdrawal method and a checkable status reference.","Evaluate coverage of a proposed read: 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.","Amend instrument: Apply a classified change to a live instrument, creating a new version, and require a fresh consent act where the change class demands one.","Terminate instrument: End a grant by withdrawal, revocation, expiry, supersession or invalidation, recording the reason, the effective instant and any reliance exception.","Propagate termination downstream: Notify every recipient that received data under the grant, collect cutoff and deletion acknowledgements, and record any recipient that cannot be reached.","Record duty discharge: Register that a grantee duty was fulfilled, with the evidence relied on, and update the duty status.","Project a view of the instrument: Return a named projection of the instrument to a requesting role — validity token, grantor ledger or grantee entitlement list — omitting everything outside that projection.","Apply retention and disposal: Evaluate the retention schedule against terminated instruments and their evidence, and minimise, anonymise, tombstone or destroy each record class accordingly.","Conflict evaluation: Detect Permission/Prohibition/Action-inheritance clashes and apply the instrument's conflict strategy or fail invalid."]},"hazards":{"applicability":"required","items":["Access granted without a valid basis.","Withdrawal not propagated, so processing continues.","Dark patterns that obtain consent without real choice."]},"interfaces":{"applicability":"required","items":["W3C ODRL Information Model 2.2.","W3C Data Privacy Vocabulary (DPV).","Kantara Initiative Consent Receipt specification.","OAuth 2.0 (RFC 6749) and User-Managed Access (UMA 2.0)."]},"context":{"applicability":"required","items":["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."]}},"sources":[{"title":"ODRL Information Model 2.2","url":"https://www.w3.org/TR/odrl-model/","note":"World Wide Web Consortium (W3C)"},{"title":"ODRL Vocabulary & Expression 2.2","url":"https://www.w3.org/TR/odrl-vocab/","note":"World Wide Web Consortium (W3C)"},{"title":"Regulation (EU) 2016/679 (General Data Protection Regulation)","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679","note":"European Parliament and Council of the European Union"},{"title":"Guidelines 05/2020 on consent under Regulation 2016/679, Version 1.1","url":"https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en","note":"European Data Protection Board"},{"title":"ISO/IEC TS 27560:2023 Privacy technologies — Consent record information structure","url":"https://www.iso.org/standard/80392.html","note":"International Organization for Standardization / International Electrotechnical Commission"},{"title":"Data Privacy Vocabulary (DPV) Version 2.1","url":"https://w3c-cg.github.io/dpv/2.1/dpv/","note":"W3C Data Privacy Vocabularies and Controls Community Group"},{"title":"HL7 FHIR Release 5: Consent resource","url":"https://www.hl7.org/fhir/consent.html","note":"Health Level Seven International"},{"title":"eXtensible Access Control Markup Language (XACML) Version 3.0","url":"https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html","note":"OASIS"},{"title":"User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization","url":"https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html","note":"Kantara Initiative"},{"title":"RFC 9396: OAuth 2.0 Rich Authorization Requests","url":"https://www.rfc-editor.org/rfc/rfc9396.html","note":"Internet Engineering Task Force (IETF)"},{"title":"45 CFR 164.508 — Uses and disclosures for which an authorization is required","url":"https://www.ecfr.gov/api/renderer/v1/content/enhanced/current/title-45?part=164&section=164.508","note":"U.S. Department of Health and Human Services (Code of Federal Regulations, eCFR)"},{"title":"Verifiable Credentials Data Model v2.0","url":"https://www.w3.org/TR/vc-data-model-2.0/","note":"World Wide Web Consortium (W3C)"},{"title":"Data Use Ontology (DUO)","url":"https://github.com/EBISPOT/DUO","note":"Global Alliance for Genomics and Health / EMBL-EBI (OBO Foundry)"},{"title":"Regulation (EU) 2022/868 on European data governance (Data Governance Act)","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R0868","note":"European Parliament and Council of the European Union"},{"title":"Consent Receipt Specification v1.1.0","url":"https://kantarainitiative.org/download/consent-receipt-specification/","note":"Kantara Initiative"},{"title":"Consent Records and Receipts as per ISO/IEC TS 27560:2023 using DPV","url":"https://w3c-cg.github.io/dpv/guides/consent-27560","note":"W3C Data Privacy Vocabularies and Controls Community Group"},{"title":"HL7 FHIR R5 Resource Consent","url":"https://hl7.org/fhir/R5/consent.html","note":"HL7 International"},{"title":"ISO/IEC 29184:2020 Information technology - Online privacy notices and consent","url":"https://www.iso.org/standard/70331.html","note":"ISO/IEC JTC 1/SC 27"},{"title":"Consent Records and Receipts as per ISO/IEC TS 27560:2023 using DPV","url":"https://w3id.org/dpv/guides/consent-27560","note":"W3C Data Privacy Vocabularies and Controls Community Group"}],"openQuestions":["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.","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."],"resources":{"spec":"/models/wm-xct-002-access-contract-consent/spec.yaml","agents":"/models/wm-xct-002-access-contract-consent/AGENTS.md","source":"https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-002"},"provenance":{"origin":"world-models research","builtFrom":["models/wm-xct-002-access-contract-consent/spec.yaml","ver-cy/world-models/card-supplements/wm-xct-002-access-contract-consent.json"],"providers":["Claude","Grok"],"researchStatus":"reviewable-draft","generatedAt":"2026-08-23T02:36:57Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"filled","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"interaction.properties":"Institutional or informational subject: no invented physical properties.","_supplement":"Sections authored in card supplement 1.0.0 by Claude (Opus 5.5) (2026-10-05, unreviewed). Written from the published specification and established practice in the field; no new sources were read. Unreviewed."},"score":1.0}}