# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-23T06:03:39Z", "synthesisSha256": "11f17ca2273d07b88689b0b9f7c43185918f51dabce9fc7ab4dc63efd178b082", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-XCT-023", "registryId": "vr.wm-xct-023", "name": "Party Role", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.ROLE" ], "tags": [ "party", "role", "xct.role" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-xct-023-party-role/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-023", "model": { "registry_id": "vr.wm-xct-023", "model_id": "WM-XCT-023", "name": "Party Role", "entry_kind": "mixin", "purpose": "Provide a reusable, format-neutral structure for asserting that a party plays a named role with respect to a specific object, activity, agreement or other party, together with the scope, validity, authority, provenance, evidence and constraints that make the assertion operable and auditable.", "scope_statement": "Party Role reifies the n-ary link (player, host context, role type, validity) as an addressable assertion so that qualifying facts can attach to it. It covers how such an assertion is identified, classified, scoped, time-bounded, delegated, evidenced, constrained, disputed, superseded, disclosed and retired. It deliberately carries no party master data, no host payload and no permission semantics; those belong to composable sibling models. The mixin is storage- and interface-neutral: RDF, JSON, tabular, document and API projections are views over the same invariants.", "in_scope": [ "Reification of the party-to-host link as a first-class role assertion with its own identity", "Role type classification, vocabulary binding strength, and mapping to external role code lists", "Host context binding: object, activity/event, agreement, organization, or another party", "Player binding across party kinds including organizations, groups, automated agents and vacant posts", "Scope qualifiers: spatial, jurisdictional, organizational-unit, quantitative extent and typed characteristics", "Role validity period separated from assertion/record time, with retroactive correction and as-of resolution", "Status lifecycle, suspension, revocation, succession, acting/interim holdings and coverage gaps", "Basis of authority: statutory, contractual, appointment-based or self-declared, with mandate references", "Delegation, acting-on-behalf-of chains, sub-delegation and representation/signing limits", "Multiplicity, exclusivity, segregation-of-duties and conflict-of-interest constraints", "Provenance of the assertion, supporting evidence, corroboration level and dispute handling", "Disclosure tiers, retention, tombstoning and erasure of person-identifying role history", "Alignment to external standards and the invariants that must survive any projection" ], "out_of_scope": [ "Party master data such as legal name, registered address, contact details or LEI registration itself", "The internal content, state or behaviour of the host object, activity or agreement", "Permission sets, entitlements and access-control decisions derived from a role", "Organizational structure, reporting hierarchy and post establishment beyond the role reference", "Agreement terms, pricing and obligations other than those attached to the role type", "Credential issuance, cryptographic proof formats and verification protocol mechanics", "Consent capture and lawful-basis determination for processing personal data", "Authentication, session and identity-assurance mechanics for the player", "Storage engine, wire format and API surface choices" ], "boundary_notes": [ { "neighbor": "Party / Agent identity model", "distinction": "A role has no independent existence apart from a player and a host; the mixin references the player by identifier and never restates party master data such as name, address or registration.", "source_refs": [ "SRC-005", "SRC-008", "SRC-017" ] }, { "neighbor": "Organization membership (W3C org:Membership, org:Post)", "distinction": "org:Membership is a role of an agent specifically within an Organization and org:Post is a holder-independent position. Party Role generalises to arbitrary hosts; where the host is an organization the two overlap and must be reconciled by an explicit ALIGN mapping rather than duplicated.", "source_refs": [ "SRC-002" ] }, { "neighbor": "Role-Based Access Control role (INCITS 359 / NIST RBAC)", "distinction": "An RBAC role is a permission-bundling construct evaluated by a policy decision point; a party role is a business or legal assertion about who stands in what relation to what. A party role may be an input to authorization but never carries permissions itself.", "source_refs": [ "SRC-015" ] }, { "neighbor": "Provenance model (W3C PROV-O)", "distinction": "prov:hadRole is scoped to prov:Association and prov:Attribution qualifications of agent involvement in activities and entities. Party Role covers standing roles that exist independently of any recorded activity, so PROV alignment is partial and must not be presented as conformance.", "source_refs": [ "SRC-001", "SRC-006" ] }, { "neighbor": "Participation / event participant records", "distinction": "A participation attaches an actor to a single act occurrence; a party role may be durable and outlive any occurrence. Occurrence-bound participations should reference a role assertion rather than duplicate it.", "source_refs": [ "SRC-006", "SRC-016" ] }, { "neighbor": "Party-to-party relationship registers (GLEIF Level 2)", "distinction": "Structural ownership and consolidation relationships are symmetric-ish records between two legal entities with their own validation regime. This boundary is genuinely fuzzy: parent/subsidiary can be read as a role. The adopting Dimension must choose one representation per relationship type and record the choice.", "source_refs": [ "SRC-008" ] }, { "neighbor": "Verifiable credential / attestation model", "distinction": "A credential is one possible evidence artifact for a role assertion. Issuer, holder, subject and verifier are roles relative to a credential exchange, not the role being asserted; conflating them produces circular models.", "source_refs": [ "SRC-004" ] }, { "neighbor": "Consent and lawful-basis model", "distinction": "Statutory role types such as controller and processor carry obligations, but the lawful basis for a given processing operation is a separate determination held elsewhere and referenced from the role assertion.", "source_refs": [ "SRC-009" ] } ] }, "sources": [ { "id": "SRC-001", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013; namespace http://www.w3.org/ns/prov#", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Normative qualification pattern for roles: prov:Role, prov:hadRole, prov:Association/qualifiedAssociation, prov:Attribution/qualifiedAttribution, prov:Delegation/qualifiedDelegation and prov:actedOnBehalfOf. Establishes reification of agent involvement and the activity-scoped restriction on hadRole." }, { "id": "SRC-002", "title": "The Organization Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-org/", "version_or_date": "W3C Recommendation, 16 January 2014; namespace http://www.w3.org/ns/org#", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Defines org:Role as an abstract role, org:Membership as an n-ary Agent-Organization-Role relation annotatable with duration and contract, org:Post as a position existing independently of its holder, org:memberDuring, org:holds and org:reportsTo." }, { "id": "SRC-003", "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; namespace http://www.w3.org/ns/odrl/2/", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Models parties as undertaking functions in rules: odrl:Party, odrl:PartyCollection, odrl:function with assigner/assignee and twelve further party functions (attributedParty, compensatedParty, consentingParty, contractingParty, informedParty, trackingParty and their converses). Demonstrates role-as-function scoped to a rule." }, { "id": "SRC-004", "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-23T00:00:00Z", "relevance": "Defines issuer, holder, subject and verifier as contextual roles ('a role is an abstraction that might be implemented in many different ways'; an entity can perform multiple roles per interaction), plus validFrom, validUntil and credentialStatus for revocation and suspension of role evidence." }, { "id": "SRC-005", "title": "Resource PractitionerRole (FHIR R5)", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/R5/practitionerrole.html", "version_or_date": "FHIR v5.0.0, published 26 March 2023; Maturity Level 4", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "A production role resource: identifier 0..*, active, period (authorization timeframe), practitioner 0..1 (may be absent for un-named organizational roles), organization, code, specialty, location, healthcareService, contact, availability. Also states boundaries against CareTeam and notes that qualifications do not imply a role." }, { "id": "SRC-006", "title": "Resource Provenance (FHIR R5)", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/R5/provenance.html", "version_or_date": "FHIR v5.0.0, published 26 March 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Separates agent.type (functional role with respect to the activity) from agent.role (structural roles indicating competency), requires agent.who, provides agent.onBehalfOf as the delegating agent with a who != onBehalfOf constraint, and separates occurred[x] from recorded. Also distinguishes Provenance from AuditEvent." }, { "id": "SRC-007", "title": "TMF669 Party Role Management API, PartyRole resource schema v4.0.0", "organization": "TM Forum", "url": "https://raw.githubusercontent.com/tmforum-apis/TMF669_PartyRole/master/TMF669-PartyRole-v4.0.0.swagger.json", "version_or_date": "TMF669 v4.0.0 OpenAPI/Swagger definition (Apache-2.0), repository tmforum-apis/TMF669_PartyRole", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Defines PartyRole as 'the part played by a party in a given context' with id, href, name, status, statusReason, validFor (TimePeriod), engagedParty (RelatedParty), relatedParty, characteristic (typed name/value), account, agreement, contactMedium, creditProfile; and four lifecycle events (Create, AttributeValueChange, StateChange, Delete)." }, { "id": "SRC-008", "title": "Level 2 Data: Relationship Record (RR) CDF Format 2.1", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format", "version_or_date": "RR-CDF version 2.1, published May 2021", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Operational registry model for asserted relationships: StartNode/EndNode by LEI or ISO 17442-compatible id, RelationshipType, three distinct RelationshipPeriods (RELATIONSHIP, ACCOUNTING, DOCUMENT_FILING), RelationshipStatus, Qualifiers/Quantifiers, and a Registration block with InitialRegistrationDate, LastUpdateDate, NextRenewalDate, nine RegistrationStatus values, ManagingLOU, four ValidationSources levels and ValidationDocuments." }, { "id": "SRC-009", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Union", "url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng", "version_or_date": "Adopted 27 April 2016; consolidated text on EUR-Lex", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Canonical example of statutory roles determined by factual conduct rather than declaration: controller Art 4(7), processor Art 4(8), recipient Art 4(9), third party Art 4(10), joint controllers Art 26 requiring a documented allocation of responsibilities, and Art 28 requiring a binding contract or legal act to govern processing." }, { "id": "SRC-010", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Mandates full date-time with mandatory seconds and an explicit numeric offset or 'Z', and reserves '-00:00' for the case where UTC is known but the local offset is not. Governs every timestamp in this model." }, { "id": "SRC-011", "title": "RFC 9562: Universally Unique IDentifiers (UUIDs)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9562.html", "version_or_date": "May 2024, Standards Track; obsoletes RFC 4122", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Defines UUIDv4 and time-ordered UUIDv7 and states that implementations SHOULD use UUIDv7 instead of UUIDv1/v6. Supplies the third tier of the identity priority when no master-system or governed global identifier exists." }, { "id": "SRC-012", "title": "Role - Schema.org Type", "organization": "Schema.org / W3C Schema.org Community Group", "url": "https://schema.org/Role", "version_or_date": "Schema.org V30.0, released 19 March 2026", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Role as an intermediary node that 'represents additional information about a relationship or property', with roleName, startDate, endDate and subtypes OrganizationRole, PerformanceRole and LinkRole. Independent confirmation of the reification pattern in a widely deployed vocabulary." }, { "id": "SRC-013", "title": "CRediT - Contributor Roles Taxonomy (ANSI/NISO Z39.104-2022)", "organization": "National Information Standards Organization (NISO)", "url": "https://credit.niso.org/", "version_or_date": "ANSI/NISO Z39.104-2022; CC-BY 4.0", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "A governed 14-term controlled vocabulary of roles scoped to a specific scholarly output, with multiple contributors permitted per role and multiple roles per contributor. Reference case for vocabulary-bound, object-scoped role classification." }, { "id": "SRC-014", "title": "DataCite Metadata Schema 4.6 - contributorType", "organization": "DataCite e.V.", "url": "https://datacite-metadata-schema.readthedocs.io/en/4.6/appendices/appendix-1/contributorType/", "version_or_date": "DataCite Metadata Schema 4.6", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "A 22-term controlled vocabulary of roles scoped to a resource, including ContactPerson, DataCurator, DataManager, Distributor, HostingInstitution, RegistrationAgency, RegistrationAuthority, RightsHolder, Sponsor, Supervisor, WorkPackageLeader and an explicit Other escape term." }, { "id": "SRC-015", "title": "Role Based Access Control (RBAC) project", "organization": "National Institute of Standards and Technology (NIST), Computer Security Resource Center", "url": "https://csrc.nist.gov/projects/role-based-access-control", "version_or_date": "INCITS 359-2012 (effective 29 May 2012), superseding ANSI/INCITS 359-2004 (adopted 11 February 2004)", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Defines an RBAC role as a job function within an organization carrying associated authority and responsibility, with user-role and permission-role assignment as separate relations and separation-of-duty constraints. Used to fix the boundary between authorization roles and party roles." }, { "id": "SRC-016", "title": "CodeSystem: v3 Code System RoleClass", "organization": "Health Level Seven International (HL7) Terminology", "url": "https://terminology.hl7.org/CodeSystem-v3-RoleClass.html", "version_or_date": "HL7 Terminology (THO) release aligned to FHIR v5.0.0", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Source of the player/scoper pattern: a Role is a competency of the Entity playing the Role as identified, defined, guaranteed or acknowledged by the Entity that scopes the Role. Grounds the requirement to model the scoping party distinctly from the host and the player. Retrieved page rendered navigation only; definitions confirmed via the same URL through the search index, so treat as lower-verification." }, { "id": "SRC-017", "title": "class - CI_Responsibility (ISO 19115-1 metadata profile documentation)", "organization": "Intergovernmental Committee on Surveying and Mapping (ICSM), Australia and New Zealand", "url": "https://icsm-au.github.io/metadata-working-group/defs/class-CI_Responsibility.html", "version_or_date": "ISO 19115-1 with 2018 amendment (partyIdentifier added); ICSM Metadata Working Group documentation", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T00:00:00Z", "relevance": "Restates ISO 19115-1 CI_Responsibility as 'information about the party and their role' with mandatory role (CI_RoleCode, 19-20 terms including custodian, owner, originator, rightsHolder, pointOfContact, distributor, processor, funder, stakeholder), a party (CI_Individual or CI_Organisation with partyIdentifier such as ORCID) and an optional extent giving the 'spatial or temporal extent of the role'. ISO 19115-1 itself is paywalled and was not directly verified." }, { "id": "SRC-018", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/2013/REC-prov-o-20130430/", "version_or_date": "W3C Recommendation 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T17:10:00Z", "relevance": "Defines prov:Role as the function of an entity or agent with respect to an activity; prov:Association as assignment of responsibility with optional hadRole, hadPlan and actedOnBehalfOf; and Agent subclasses Person, Organization and SoftwareAgent." }, { "id": "SRC-019", "title": "FHIR Resource PractitionerRole", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/practitionerrole.html", "version_or_date": "FHIR R5 5.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T17:15:00Z", "relevance": "Normative pattern for a standing actor-role assignment: identifiers, active flag, authorised period, practitioner, organisation, role codes, specialty, locations, healthcare services, and explicit boundaries with qualifications and CareTeam." }, { "id": "SRC-020", "title": "unece:PartyRoleCodeList", "organization": "United Nations Economic Commission for Europe (UN/CEFACT)", "url": "https://vocabulary.uncefact.org/PartyRoleCodeList", "version_or_date": "UN/CEFACT BSP vocabulary, page accessed 2026-08-23", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T17:40:00Z", "relevance": "Authoritative multi-industry party-role code list (buyer, consignee, carrier, authorised official, temporary employee, agent/representative direct and indirect, and hundreds of trade, transport, energy and healthcare functions)." }, { "id": "SRC-021", "title": "HL7 CodeSystem RoleClass", "organization": "Health Level Seven International (HL7)", "url": "https://terminology.hl7.org/en/CodeSystem-v3-RoleClass.html", "version_or_date": "RoleClass 6.0.0; THO 7.3.0; active as of 2019-03-20", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T17:35:00Z", "relevance": "Defines Role as association between playing entity and scoping entity; distinguishes AssignedEntity from Employee, Agent/on-behalf-of, signing authority, licensed entity, qualified entity, vacant-capable assigned posts, and excludes partitive/ontological/passive material roles from this mixin." }, { "id": "SRC-022", "title": "ISO20022 types — Role and PartyRole component restructure", "organization": "IBM (documenting the ISO 20022 business model)", "url": "https://www.ibm.com/docs/en/ftmfm/4.0.8?topic=types-iso20022", "version_or_date": "IBM FTM 4.0.8, documentation dated 2026-04-30", "source_type": "secondary", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-23T17:30:00Z", "relevance": "Describes the ISO 20022 Role component as the association of a Party with another component plus business intention, and the repeating PartyRole element (DebtorRole, CreditorRole, UltimateDebtorRole, AccountOwnerRole and related extensions). Not a substitute for the ISO 20022 Registration Authority dictionary." }, { "id": "SRC-023", "title": "unece:partyRoleCode", "organization": "United Nations Economic Commission for Europe (UN/CEFACT)", "url": "https://vocabulary.uncefact.org/partyRoleCode", "version_or_date": "UN/CEFACT vocabulary page dated 2024-09-16", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T17:25:00Z", "relevance": "Defines partyRoleCode as a code specifying the role of a trade party or transport person, ranging over PartyRoleCodeList and domain-typed to TradeParty and TransportPerson." }, { "id": "SRC-024", "title": "FHIR Resource Provenance", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/provenance.html", "version_or_date": "FHIR R5 5.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T18:50:00Z", "relevance": "Maps W3C PROV into FHIR: agent who/onBehalfOf, occurred versus recorded time, participation type versus security role, and constraints that who and onBehalfOf cannot be the same. Distinguishes activity-scoped participation from standing PractitionerRole." } ], "structure": { "bundles": [ { "id": "assertion-core", "name": "Role Assertion Core", "description": "What a Party Role assertion is, how it is identified, and how its role type is classified and governed.", "rationale": "Every downstream concern depends on the assertion being an addressable thing with stable identity and a governed classification. PROV-O, org and schema.org independently converge on reifying the agent-to-context link, and TMF669 and FHIR show it operationally as a resource with its own identifier.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-007", "SRC-012", "SRC-016" ], "layers": [ { "id": "reification-and-identity", "name": "Reification and Assertion Identity", "description": "The role assertion as a first-class reified n-ary link, and the rules that decide when two records denote the same assertion.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-011", "SRC-012", "SRC-016" ], "findings": [ { "id": "role-assertion-reification", "name": "Role assertion as a reified n-ary link", "description": "Party Role is not a binary property between a party and a host. It is a reified node joining player, host context, role type and validity, so that qualifying facts such as period, extent, evidence and delegation can attach without polluting either endpoint.", "source_refs": [ "SRC-001", "SRC-002", "SRC-012", "SRC-016" ], "questions": [ { "id": "q-reify-trigger", "text": "When must a party-to-host link be reified as a Party Role assertion rather than expressed as a direct binary property?", "kind": "composition", "answer_data": [ "Reification trigger rule expressed over required qualifying facts", "List of qualifying facts (period, extent, evidence, delegation, share) that force reification", "Name of the permitted binary shorthand property, if any" ] }, { "id": "q-minimal-tuple", "text": "What is the minimal tuple that makes a Party Role assertion well-formed?", "kind": "definition", "answer_data": [ "Ordered list of mandatory slots (player reference, host reference, role type, valid-from)", "Well-formedness rule identifier and its failure codes", "Treatment of an assertion with an unresolvable endpoint" ] }, { "id": "q-scoper-distinct", "text": "Is there a scoping party distinct from the host that defines or acknowledges the role, and how is it recorded?", "kind": "relationship", "answer_data": [ "Scoping party reference", "Rule distinguishing scoper from host and from player", "Cases where scoper and host coincide" ] }, { "id": "q-shorthand-loss", "text": "Which facts are lost when the assertion is projected to a binary shorthand, and is the projection declared lossy?", "kind": "interoperability", "answer_data": [ "Derivation rule from reified form to shorthand", "Enumerated lossy-field list", "Lossy-projection warning flag" ] } ], "data_elements": [ { "id": "role-assertion", "name": "Role assertion", "description": "The reified node joining player, host, role type and validity; the unit of identity for this mixin.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ] }, { "id": "player-ref", "name": "Player reference", "description": "Reference to the party that plays the role; never an embedded copy of party master data.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-006", "SRC-016" ] }, { "id": "host-context-ref", "name": "Host context reference", "description": "Reference to the object, activity, agreement, organization or party the role is scoped to.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-006", "SRC-017" ] }, { "id": "scoping-party-ref", "name": "Scoping party reference", "description": "Party that identifies, defines, guarantees or acknowledges the role, where distinct from the host.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "role-assertion-record", "name": "Role assertion record", "description": "The addressable record of one reified role assertion, carrying its identity, endpoints, type, validity and qualifying facts.", "media_or_form": [ "structured record", "graph node with qualifying properties", "register entry" ], "serial": false, "identity_strategy": "Authoritative master-system identifier where an owning system exists; otherwise a governed IRI minted in the Dimension namespace; otherwise a UUIDv7 per RFC 9562. Never keyed on player name, role label or a date.", "source_refs": [ "SRC-007", "SRC-011", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "assertion-identifier-and-sameness", "name": "Assertion identifier and sameness rules", "description": "Which identifier governs the assertion, what is minted when none exists, and which attribute changes create a new assertion rather than a new version of the existing one.", "source_refs": [ "SRC-005", "SRC-007", "SRC-008", "SRC-011" ], "questions": [ { "id": "q-master-identifier", "text": "Which authoritative master-system identifier governs this role assertion, and which body issues it?", "kind": "identity", "answer_data": [ "Primary identifier value and scheme", "Issuing authority reference and its registry", "Identifier priority tier actually applied" ] }, { "id": "q-minted-identifier", "text": "What identifier is minted when no authoritative master-system or governed global identifier exists?", "kind": "identity", "answer_data": [ "Minting rule naming UUIDv7 or ULID and the minting service", "Dimension namespace base for locally minted IRIs", "Assertion that no date or label is used as an identifier" ] }, { "id": "q-new-vs-version", "text": "Which attribute changes create a new assertion rather than a new version of the existing one?", "kind": "identity", "answer_data": [ "Identity-bearing attribute set (natural key)", "Version-only attribute set", "Split and merge handling rule" ] }, { "id": "q-duplicate-merge", "text": "How are duplicate assertions contributed by multiple systems detected, ranked and merged?", "kind": "quality", "answer_data": [ "Natural-key fingerprint definition", "Source precedence order", "Surviving-identifier and alias-retention rule" ] } ], "data_elements": [ { "id": "assertion-id", "name": "Assertion identifier", "description": "The governing identifier of the role assertion.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-011" ] }, { "id": "assertion-id-scheme", "name": "Identifier scheme", "description": "Scheme or issuing authority of the governing identifier.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-011" ] }, { "id": "assertion-alternate-id", "name": "Alternate identifier", "description": "Identifiers held for the same assertion in contributing systems, retained after merge.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "assertion-natural-key", "name": "Natural key fingerprint", "description": "Deterministic fingerprint over the identity-bearing attribute set, used for duplicate detection.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "identifier-allocation-register", "name": "Identifier allocation register", "description": "Register of identifiers minted for role assertions, their scheme, minting time and any aliases retained through merges.", "media_or_form": [ "append-only register", "tabular extract" ], "serial": true, "identity_strategy": "Register keyed by the governing assertion identifier; each register entry carries its own UUIDv7 and RFC 3339 minting timestamp.", "source_refs": [ "SRC-008", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "classification-and-vocabulary", "name": "Role Classification and Vocabulary", "description": "The role type itself, the axis it expresses, and the governance of the vocabulary that supplies it.", "source_refs": [ "SRC-001", "SRC-006", "SRC-013", "SRC-014", "SRC-017" ], "findings": [ { "id": "role-type-and-axes", "name": "Role type and classification axes", "description": "A role type must declare which axis it expresses. FHIR Provenance separates the functional role with respect to an activity from the structural role indicating competency; contractual and statutory positions form further axes. Collapsing them produces vocabularies that cannot be validated.", "source_refs": [ "SRC-001", "SRC-006", "SRC-013", "SRC-014", "SRC-017" ], "questions": [ { "id": "q-classification-axis", "text": "Which axis does this role type express: functional participation, structural competency, contractual position or statutory status?", "kind": "classification", "answer_data": [ "Axis code from a closed enumeration", "Rationale note where the type spans axes", "Validation rule preventing cross-axis substitution" ] }, { "id": "q-vocabulary-binding", "text": "Which controlled vocabulary and version supplies the role type, and what is the binding strength?", "kind": "classification", "answer_data": [ "Vocabulary IRI and version identifier", "Binding strength (required, extensible, preferred, example)", "Term IRI and its label at time of assertion" ] }, { "id": "q-multiple-types", "text": "May one assertion carry more than one role type, and how is a multi-typed assertion interpreted?", "kind": "constraint", "answer_data": [ "Multiplicity rule for role type", "Conjunctive or disjunctive interpretation", "Decomposition rule into single-typed assertions" ] }, { "id": "q-unmapped-term", "text": "How is a local or unmapped role term carried without breaking consumers bound to the governed vocabulary?", "kind": "interoperability", "answer_data": [ "Local-term namespace and escape term (for example an explicit Other)", "Free-text label field paired with the escape term", "Consumer fallback behaviour" ] } ], "data_elements": [ { "id": "role-type-code", "name": "Role type code", "description": "The governed term identifying the role played.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-013", "SRC-014", "SRC-017" ] }, { "id": "role-type-scheme", "name": "Role type scheme and version", "description": "IRI and version of the vocabulary from which the role type is drawn.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "role-classification-axis", "name": "Classification axis", "description": "Whether the type is functional, structural, contractual or statutory.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "role-type-binding-strength", "name": "Binding strength", "description": "How strictly the vocabulary constrains the value.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Classification on an assertion is a coded reference resolved against the vocabulary release artifact governed in the sibling finding. Emitting a separate per-assertion classification artifact would duplicate that release and create a second, divergent source of term definitions." }, { "id": "role-vocabulary-governance", "name": "Role vocabulary governance", "description": "Who owns the role-type vocabulary, how terms are admitted, deprecated and mapped, and what consumers must do when they meet an unknown term from a newer version.", "source_refs": [ "SRC-005", "SRC-006", "SRC-013", "SRC-014", "SRC-017" ], "questions": [ { "id": "q-vocab-authority", "text": "Who owns the role-type vocabulary and by what process are new terms admitted or rejected?", "kind": "authority", "answer_data": [ "Vocabulary owner and decision body", "Term-admission process reference and evidence requirements", "Publication cadence and change-notice channel" ] }, { "id": "q-term-deprecation", "text": "How are deprecated or superseded terms handled in assertions that already cite them?", "kind": "lifecycle", "answer_data": [ "Term status values (active, deprecated, retired)", "Successor-term mapping", "Whether historical assertions are rewritten or frozen" ] }, { "id": "q-unknown-term-behaviour", "text": "What behaviour is required when a consumer encounters a term from a newer vocabulary version than it knows?", "kind": "interoperability", "answer_data": [ "Required consumer behaviour (reject, pass through, degrade to broader term)", "Minimum supported vocabulary version declaration", "Version negotiation mechanism" ] }, { "id": "q-term-hierarchy", "text": "Are role terms hierarchical, and does a broader term subsume assertions made with a narrower one?", "kind": "classification", "answer_data": [ "Broader/narrower term relations", "Subsumption rule for queries", "Depth limit and cycle prohibition" ] } ], "data_elements": [ { "id": "vocabulary-release-id", "name": "Vocabulary release identifier", "description": "Identifier and version of a published role-type vocabulary release.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "term-status", "name": "Term status", "description": "Lifecycle state of a role term within its vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "term-broader-ref", "name": "Broader term reference", "description": "Reference to a broader role term for subsumption reasoning.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-017" ] }, { "id": "term-successor-ref", "name": "Successor term reference", "description": "Replacement term for a deprecated or retired role term.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "role-type-vocabulary-release", "name": "Role type vocabulary release", "description": "A versioned, citable release of the role-type vocabulary with term IRIs, definitions, axis assignment, status and broader/successor relations.", "media_or_form": [ "controlled vocabulary release", "concept scheme", "code list" ], "serial": true, "identity_strategy": "Governed vocabulary IRI plus an immutable version identifier; each release carries an RFC 3339 publication timestamp and never reuses a retired term IRI for a new meaning.", "source_refs": [ "SRC-013", "SRC-014", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "role-class-kind-exclusions", "name": "Role-class kind and exclusions", "description": "HL7 RoleClass partitions roles into ontological, partitive and associative (mutual/formal versus passive). This mixin is limited to associative actor functions (especially AssignedEntity, Agent, licensed/qualified as constraints). Ingredient, instance-of-kind and owned-material roles are out of scope.", "source_refs": [ "SRC-021" ], "questions": [ { "id": "role-class-kind-exclusions-q01", "text": "Which RoleClass kind (assigned, agent, licensed, other associative) does this assignment instantiate?", "kind": "classification", "answer_data": [ "role_class_kind", "hl7_roleclass_code" ] }, { "id": "role-class-kind-exclusions-q02", "text": "Has this record been rejected because it is partitive, ontological or a passive material role?", "kind": "validation", "answer_data": [ "exclusion_reason", "rejected_roleclass_code" ] }, { "id": "role-class-kind-exclusions-q03", "text": "Is this assignment a functional AssignedEntity role, an EMP employment relationship, or both as separate records?", "kind": "classification", "answer_data": [ "assigned_entity_ref", "employment_ref", "separation_asserted" ] } ], "data_elements": [ { "id": "role-class-kind-exclusions-data01", "name": "Role class kind", "description": "High-level kind of the assignment within the associative actor subset.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "role-class-kind-exclusions-data02", "name": "HL7 RoleClass code", "description": "Optional alignment code such as ASSIGNED, AGNT, SGNOFF, LIC, QUAL, EMP.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "Kind and exclusion flags are classifiers on the assignment; they are not independent artefacts." } ] } ] }, { "id": "scoping-and-composition", "name": "Scoping and Composition", "description": "What the role attaches to, who may play it, and how the role is narrowed within its host.", "rationale": "The registry purpose is explicitly 'actor role scoped to an object or activity'. Scoping is therefore the defining axis of the model and is where standards disagree most: PROV-O restricts hadRole to activity associations, ISO 19115-1 scopes responsibility to a described resource, and FHIR and TMF669 scope to organizations, locations, services and agreements.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-017" ], "layers": [ { "id": "host-context-binding", "name": "Host Context Binding", "description": "The kinds of host a role may attach to, how the host is referenced, and whether roles cascade to parts and successors.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-017" ], "findings": [ { "id": "host-kind-and-reference", "name": "Host kind and reference integrity", "description": "The host discriminator and the referencing rule that keeps an assertion resolvable when the host is versioned, merged or superseded. PROV separates activity association from entity attribution; ISO 19115-1 binds a party to a role relative to a described resource; TMF669 binds roles to accounts and agreements.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-017" ], "questions": [ { "id": "q-host-kind", "text": "What kind of host does this role attach to: an object, an activity or event, an agreement, an organization, or another party?", "kind": "composition", "answer_data": [ "Host kind code from a closed enumeration", "Permitted role types per host kind", "Rule for hosts that are themselves role assertions" ] }, { "id": "q-host-ref-stability", "text": "How is the host referenced so the assertion stays resolvable when the host is versioned or re-identified?", "kind": "relationship", "answer_data": [ "Host identifier and scheme", "Version-pinned versus version-floating reference mode", "Redirect and alias resolution policy" ] }, { "id": "q-multi-host", "text": "May one assertion span multiple hosts, or is a separate assertion required per host?", "kind": "constraint", "answer_data": [ "Multi-host permission rule", "Uniform-application caveat where several hosts are listed", "Decomposition rule when qualifiers differ per host" ] }, { "id": "q-host-disposal", "text": "What happens to the assertion when its host is deleted, merged or superseded?", "kind": "lifecycle", "answer_data": [ "Cascade action (retire, re-point, orphan-flag)", "Orphaned-assertion handling and review queue", "Retention obligation for the orphaned record" ] } ], "data_elements": [ { "id": "host-kind", "name": "Host kind", "description": "Discriminator for the category of host the role is scoped to.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ] }, { "id": "host-version-ref", "name": "Host version reference", "description": "Version-pinned reference where the role is asserted against a specific host version.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "host-ref-mode", "name": "Host reference mode", "description": "Whether the reference floats to the current host or pins to a version.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "The host binding is an inline reference on the role assertion record and produces no separate exchangeable object; its integrity is maintained by the referencing policy and by the assertion record artifact already defined in the reification finding." }, { "id": "scope-cascade-and-derivation", "name": "Scope cascade, inheritance and derived holdings", "description": "Whether a role asserted on a container reaches its parts, whether transitive holdings are distinguished from direct ones, and whether derived assertions are materialised or computed.", "source_refs": [ "SRC-002", "SRC-005", "SRC-008" ], "questions": [ { "id": "q-cascade-mode", "text": "Does a role asserted on a container host apply to its parts, and is that reach materialised or computed at query time?", "kind": "composition", "answer_data": [ "Cascade mode (none, computed, materialised)", "Part-of relation used for traversal", "Override rule when a part carries its own assertion" ] }, { "id": "q-direct-vs-indirect", "text": "Are direct and indirect holdings distinguished, and how is the derivation path recorded?", "kind": "relationship", "answer_data": [ "Directness flag", "Source assertion reference and derivation depth", "Maximum traversal depth and cycle guard" ] }, { "id": "q-successor-carryover", "text": "When a host is derived from or supersedes another, do existing roles carry over automatically?", "kind": "lifecycle", "answer_data": [ "Carry-over rule per role type", "Re-assertion requirement and its trigger", "Evidence needed to justify carry-over" ] } ], "data_elements": [ { "id": "cascade-mode", "name": "Cascade mode", "description": "How a role on a container reaches contained hosts.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "derived-assertion-flag", "name": "Derived assertion flag", "description": "Marks an assertion produced by derivation rather than direct assertion.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "derivation-source-ref", "name": "Derivation source reference", "description": "The assertion from which a derived holding was computed.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "derivation-depth", "name": "Derivation depth", "description": "Number of traversal steps between the direct assertion and the derived holding.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "role-derivation-ruleset", "name": "Role derivation ruleset", "description": "Declarative rules stating, per role type and host kind, whether roles cascade, over which relation, to what depth, and how conflicts with direct assertions are resolved.", "media_or_form": [ "declarative ruleset", "versioned policy document" ], "serial": false, "identity_strategy": "Governed ruleset IRI in the Dimension namespace with an immutable version identifier and RFC 3339 effective-from timestamp.", "source_refs": [ "SRC-002", "SRC-005", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "player-binding", "name": "Player Binding", "description": "Which parties may play a role, how vacancy is expressed, and how player identity is resolved and re-verified.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005", "SRC-006", "SRC-008", "SRC-011", "SRC-017" ], "findings": [ { "id": "player-kind-and-vacancy", "name": "Admissible player kinds and vacancy", "description": "Roles may be played by natural persons, organizations, collectives, automated agents, or by nobody at all. FHIR permits a PractitionerRole with an empty practitioner for organizational role tracking, and the W3C Organization Ontology defines a Post that exists independently of the person filling it.", "source_refs": [ "SRC-002", "SRC-003", "SRC-005", "SRC-006" ], "questions": [ { "id": "q-player-kinds", "text": "Which party kinds are admissible players for this role type: natural person, organization, group, automated agent, or an unfilled post?", "kind": "constraint", "answer_data": [ "Admissible player-kind set per role type", "Rejection codes for inadmissible kinds", "Whether a device or software agent may be a player" ] }, { "id": "q-vacancy", "text": "How is a vacant or not-yet-assigned position represented distinctly from a terminated role?", "kind": "state", "answer_data": [ "Vacancy status value", "Position reference held without a player", "Escalation trigger and deadline for filling the vacancy" ] }, { "id": "q-collective-holding", "text": "May a collective such as a team, committee or class of parties hold the role as a single player?", "kind": "composition", "answer_data": [ "Collective-player permission per role type", "Collective membership reference and its owning model", "Whether individual accountability must also be recorded" ] }, { "id": "q-automated-agent", "text": "Are automated or AI agents permitted players, and what additional attribution is required when they are?", "kind": "authority", "answer_data": [ "Automated-agent permission rule", "Required responsible-human on-behalf-of reference", "Agent version and operator identification" ] } ], "data_elements": [ { "id": "player-kind", "name": "Player kind", "description": "Category of party occupying the player slot.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "position-ref", "name": "Position reference", "description": "Reference to a holder-independent position or role specification the assertion instantiates.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-007" ] }, { "id": "vacancy-status", "name": "Vacancy status", "description": "Whether the position is filled, vacant or in handover.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-005" ] }, { "id": "collective-player-flag", "name": "Collective player flag", "description": "Marks a player that is a collection of parties rather than a single party.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "role-position-definition", "name": "Role position definition", "description": "A holder-independent specification of a role position: its type, host binding, admissible player kinds, obligations, cardinality and required evidence, instantiated by concrete assertions.", "media_or_form": [ "specification record", "position/post definition" ], "serial": false, "identity_strategy": "Governed position IRI issued by the organization that establishes the position; falls back to a Dimension-minted UUIDv7 where no establishing register exists.", "source_refs": [ "SRC-002", "SRC-005", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "player-identity-resolution", "name": "Player identity resolution and re-verification", "description": "The identifier priority used to bind the player, how the assertion survives upstream merge or split of the party, and whether pseudonymous or position-only holding is permitted.", "source_refs": [ "SRC-004", "SRC-005", "SRC-008", "SRC-011", "SRC-017" ], "questions": [ { "id": "q-player-id-priority", "text": "Which identifier scheme authoritatively identifies the player, and what is the documented fallback order?", "kind": "identity", "answer_data": [ "Primary player identifier and scheme (for example LEI or ORCID)", "Fallback order down to a Dimension-minted UUIDv7", "Scheme-specific validation rule" ] }, { "id": "q-player-merge", "text": "How is the assertion kept correct when the player is merged, split or re-identified upstream?", "kind": "lifecycle", "answer_data": [ "Upstream change notification channel", "Re-point versus re-assert decision rule", "Superseded-identifier alias retention" ] }, { "id": "q-pseudonymous-player", "text": "May a player be pseudonymous or identified only by position, and under what conditions?", "kind": "privacy", "answer_data": [ "Pseudonymity permission per role type and disclosure tier", "Re-identification custodian and procedure", "Conditions under which pseudonymity must be lifted" ] }, { "id": "q-player-reverification", "text": "How often must player identity be re-verified, and what happens if re-verification lapses?", "kind": "validation", "answer_data": [ "Re-verification interval and next-due timestamp", "Verification method and evidence reference", "Lapse consequence (status change, suppression, escalation)" ] } ], "data_elements": [ { "id": "player-identifier", "name": "Player identifier", "description": "The governing identifier of the player, with its scheme.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-011", "SRC-017" ] }, { "id": "player-identity-verified-at", "name": "Player identity verified at", "description": "RFC 3339 timestamp of the most recent successful identity verification of the player.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-008", "SRC-010" ] }, { "id": "player-resolution-status", "name": "Player resolution status", "description": "Whether the player reference currently resolves, is stale, or is orphaned.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "player-pseudonym-flag", "name": "Pseudonymous player flag", "description": "Marks that the player is held under a pseudonym or position-only reference.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] } ], "artifacts": [ { "id": "player-identity-resolution-log", "name": "Player identity resolution log", "description": "Log of resolution, re-pointing, merge and verification actions taken on player references, with the evidence and agent for each action.", "media_or_form": [ "append-only log", "audit extract" ], "serial": true, "identity_strategy": "Each entry carries a UUIDv7 and an RFC 3339 recorded-at instant; entries reference the assertion identifier and the player identifier before and after the action.", "source_refs": [ "SRC-006", "SRC-008", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "scope-qualifiers", "name": "Scope Qualifiers and Extent", "description": "Qualifiers that narrow a role within its host: spatial and temporal extent, jurisdiction, organizational unit, quantitative extent and typed characteristics.", "source_refs": [ "SRC-003", "SRC-005", "SRC-007", "SRC-008", "SRC-017" ], "findings": [ { "id": "role-extent-and-characteristics", "name": "Role extent, quantifiers and typed characteristics", "description": "ISO 19115-1 gives CI_Responsibility an extent for the spatial or temporal extent of the role; FHIR narrows a role by location, specialty and service; GLEIF carries relationship qualifiers and quantifiers; TMF669 carries typed name/value characteristics. Together these define how a role is narrowed without multiplying role types.", "source_refs": [ "SRC-003", "SRC-005", "SRC-007", "SRC-008", "SRC-017" ], "questions": [ { "id": "q-spatial-extent", "text": "What spatial, jurisdictional or organizational-unit extent narrows this role within its host?", "kind": "spatial", "answer_data": [ "Spatial extent geometry or named place reference", "Jurisdiction codes governing the role", "Organizational unit or location references" ] }, { "id": "q-quantitative-extent", "text": "Is a quantitative extent such as a share, quota or threshold part of the role, and in what unit?", "kind": "measurement", "answer_data": [ "Quantifier value with unit and, for monetary values, currency", "Measurement basis and as-at date", "Whether quantifiers across joint holders must sum to a total" ] }, { "id": "q-characteristic-typing", "text": "Which role-specific characteristics are permitted, and are their names and value types validated?", "kind": "constraint", "answer_data": [ "Permitted characteristic name set per role type", "Value type declaration and validation rule", "Prohibition on smuggling identity or permission data into characteristics" ] }, { "id": "q-qualifier-vs-split", "text": "Do differing qualifiers narrow a single assertion or require separate assertions?", "kind": "composition", "answer_data": [ "Uniform-application rule for listed qualifiers", "Split rule where qualifiers differ", "Worked example of the split" ] } ], "data_elements": [ { "id": "role-extent-spatial", "name": "Role spatial extent", "description": "Spatial extent within which the role applies.", "value_kind": "geometry", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "role-jurisdiction", "name": "Role jurisdiction", "description": "Jurisdiction whose law or rules govern the role within its extent.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-017" ] }, { "id": "role-quantifier", "name": "Role quantifier", "description": "Quantitative extent of the role such as share, quota or limit, with unit.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "role-characteristic", "name": "Role characteristic", "description": "Typed name/value pair carrying role-type-specific detail.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "organizational-unit-ref", "name": "Organizational unit reference", "description": "Unit, location or service line within which the role is exercised.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "role-scope-profile", "name": "Role scope profile", "description": "Per role type, the permitted qualifier dimensions, their value spaces, units, validation rules and the split rule that applies when qualifiers diverge.", "media_or_form": [ "profile document", "schema constraint set" ], "serial": false, "identity_strategy": "Governed profile IRI plus immutable version; bound to a role type IRI and a vocabulary release identifier.", "source_refs": [ "SRC-005", "SRC-007", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "role-local-contact-context", "name": "Role-local contact and service context", "description": "FHIR records telecom, availability and endpoints on PractitionerRole because they belong to the post, not the person. ISO 19115-1 CI_Party carries contactInfo for the responsible party in that role. Role-local channels must not overwrite party-master contacts.", "source_refs": [ "SRC-019", "SRC-017" ], "questions": [ { "id": "role-local-contact-context-q01", "text": "What contact channels, endpoints or availability windows belong to this assignment rather than to the player master?", "kind": "relationship", "answer_data": [ "role_contacts", "endpoints", "availability" ] }, { "id": "role-local-contact-context-q02", "text": "When role-local contact differs from party-master contact, which must operational systems use?", "kind": "decision", "answer_data": [ "preferred_contact_source", "override_rule" ] }, { "id": "role-local-contact-context-q03", "text": "Does a change of telecom or availability require a new assignment record, as FHIR recommends when details are not uniform?", "kind": "lifecycle", "answer_data": [ "split_required", "changed_fields" ] } ], "data_elements": [ { "id": "role-local-contact-context-data01", "name": "Role-local contact", "description": "Contact points that apply while occupying this role.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-017" ] }, { "id": "role-local-contact-context-data02", "name": "Role endpoint", "description": "Electronic service endpoint associated with the assignment.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "Role-local contacts are inline structured values or references to a contact sibling; they are not independent artefacts unless issued as a public directory extract." } ] } ] }, { "id": "temporal-state-lifecycle", "name": "Time, State and Lifecycle", "description": "When the role holds, when the system knew it, how its state changes, and how accountability passes between holders.", "rationale": "Roles are inherently time-bounded competencies. Every reviewed standard carries a period (org:memberDuring, FHIR period, TMF validFor, schema.org startDate/endDate, VC validFrom/validUntil), and GLEIF separately distinguishes the relationship period from registration and filing periods, which is exactly the bitemporal separation an agent needs to answer as-of questions.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-010", "SRC-012" ], "layers": [ { "id": "validity-and-time-semantics", "name": "Validity Periods and Time Semantics", "description": "The role period, its boundary and precision semantics, and the separation of role time from record time.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-010", "SRC-012" ], "findings": [ { "id": "role-validity-period", "name": "Role validity period", "description": "The interval during which the role holds, expressed as RFC 3339 date-times with mandatory seconds and an explicit offset or Z, with declared boundary inclusivity and precision.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-007", "SRC-010", "SRC-012" ], "questions": [ { "id": "q-period-bounds", "text": "What are the start and end instants of the role period, and how is an open-ended role expressed?", "kind": "temporal", "answer_data": [ "valid-from as RFC 3339 date-time with explicit offset or Z", "valid-until, or an explicit open-ended marker rather than a sentinel date", "Rule forbidding null-as-unbounded ambiguity" ] }, { "id": "q-boundary-semantics", "text": "Are period boundaries inclusive or exclusive, and at what precision are they compared?", "kind": "temporal", "answer_data": [ "Boundary inclusivity convention for start and end", "Comparison precision (second, day) and rounding rule", "Handling of zero-length and instantaneous roles" ] }, { "id": "q-intermittent-period", "text": "How is a recurring, rota-based or on-call role period represented without exploding into thousands of assertions?", "kind": "temporal", "answer_data": [ "Recurrence or availability expression", "Exception dates and blackout periods", "Relationship between the recurrence and the enclosing validity period" ] }, { "id": "q-offset-authority", "text": "Which offset is recorded, and is it the offset legally relevant to the host's jurisdiction?", "kind": "temporal", "answer_data": [ "Recorded offset and its provenance", "Jurisdictional time zone identifier where legal effect depends on local time", "Rule for '-00:00' meaning unknown local offset" ] } ], "data_elements": [ { "id": "valid-from", "name": "Valid from", "description": "Instant at which the role begins to hold, in RFC 3339 form with seconds and an explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-010", "SRC-012" ] }, { "id": "valid-until", "name": "Valid until", "description": "Instant at which the role ceases to hold; absent means open-ended, expressed by an explicit marker.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-007", "SRC-010" ] }, { "id": "period-boundary-semantics", "name": "Period boundary semantics", "description": "Declared inclusivity and comparison precision for the role period.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "role-recurrence", "name": "Role recurrence expression", "description": "Recurrence or availability pattern for intermittent holdings, with exceptions.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "The validity period is intrinsic inline data on the role assertion record and is never exchanged independently of it; publishing a separate period artifact would allow period and assertion to diverge, which is precisely the failure mode the reification pattern exists to prevent." }, { "id": "assertion-time-and-correction", "name": "Assertion time, period types and retroactive correction", "description": "Separation of when the role held from when the register learned it, so that a retroactive correction can be told apart from a genuine change, and 'as of D, as known on E' queries can be answered.", "source_refs": [ "SRC-006", "SRC-008", "SRC-010" ], "questions": [ { "id": "q-recorded-vs-occurred", "text": "When was the assertion recorded, and how does that differ from when the role took effect?", "kind": "temporal", "answer_data": [ "recorded-at instant distinct from valid-from", "observation or ingestion instant where a third system supplied the fact", "Latency threshold that triggers review" ] }, { "id": "q-correction-vs-change", "text": "How is a retroactive correction of an erroneous record distinguished from a genuine change in the role itself?", "kind": "provenance", "answer_data": [ "Correction-of reference to the superseded version", "Change reason code separating correction from real-world change", "Whether the superseded version remains readable" ] }, { "id": "q-as-of-query", "text": "Can the register answer who held role R on host H as of date D as known on date E?", "kind": "temporal", "answer_data": [ "Bitemporal index guarantee and its supported axes", "Query contract and its response shape", "Documented limits where only one time axis is retained" ] }, { "id": "q-period-types", "text": "Which period types beyond the role period are tracked for this assertion?", "kind": "temporal", "answer_data": [ "Enumerated period types (role, document filing, accounting, review, renewal)", "Period type code and its interval", "Next renewal or review due instant" ] } ], "data_elements": [ { "id": "recorded-at", "name": "Recorded at", "description": "Instant at which the assertion was recorded in the register, distinct from when the role took effect.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-008", "SRC-010" ] }, { "id": "observed-at", "name": "Observed at", "description": "Instant at which the asserting system observed or ingested the underlying fact.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "correction-of-ref", "name": "Correction of", "description": "Reference to the assertion version this record corrects.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-008" ] }, { "id": "period-type", "name": "Period type", "description": "Which kind of period an interval on the assertion represents.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "next-renewal-at", "name": "Next renewal due", "description": "Instant by which the assertion must be renewed or revalidated.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] } ], "artifacts": [ { "id": "role-assertion-version-history", "name": "Role assertion version history", "description": "The ordered set of versions of one assertion, each with its recorded-at instant, change reason, correction linkage and the agent responsible, sufficient to reconstruct any as-of view.", "media_or_form": [ "append-only version series", "change feed" ], "serial": true, "identity_strategy": "Keyed by the assertion identifier plus a monotonic version number; each version additionally carries a UUIDv7 and an RFC 3339 recorded-at instant.", "source_refs": [ "SRC-006", "SRC-008", "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "status-and-succession", "name": "Status Lifecycle and Succession", "description": "The permitted states of an assertion, the events that move it between them, and how accountability passes from one holder to the next.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-007", "SRC-008" ], "findings": [ { "id": "role-status-lifecycle", "name": "Status lifecycle and state transitions", "description": "Two state machines must be kept apart: the substantive state of the role and the registration state of the record. GLEIF separates RelationshipStatus from a nine-value RegistrationStatus; TMF669 carries status with statusReason and emits an explicit state-change event.", "source_refs": [ "SRC-004", "SRC-005", "SRC-007", "SRC-008" ], "questions": [ { "id": "q-state-set", "text": "What is the permitted state set for a role assertion, and which transitions are legal?", "kind": "state", "answer_data": [ "Enumerated states and the legal transition matrix", "Terminal states and whether reactivation is permitted", "Rejection codes for illegal transitions" ] }, { "id": "q-record-vs-role-state", "text": "Is the registration state of the record kept distinct from the substantive state of the role?", "kind": "state", "answer_data": [ "Separate role-status and registration-status fields", "Cross-consistency rules between the two", "Worked case where an active role has a pending record" ] }, { "id": "q-status-reason", "text": "Which reason codes must accompany suspension, revocation and termination?", "kind": "state", "answer_data": [ "Reason code vocabulary per transition", "Mandatory free-text justification threshold", "Whether the reason is disclosable to the player" ] }, { "id": "q-lapse-automation", "text": "Does expiry of the validity period change status automatically, or is an explicit transition event required?", "kind": "event", "answer_data": [ "Automatic-lapse rule and the emitting component", "State-change event type and payload", "Grace period before lapse takes effect" ] } ], "data_elements": [ { "id": "role-status", "name": "Role status", "description": "Substantive state of the role such as proposed, active, suspended, ended or revoked.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-007", "SRC-008" ] }, { "id": "registration-status", "name": "Registration status", "description": "State of the record itself such as pending validation, published, lapsed or retired.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "status-reason-code", "name": "Status reason code", "description": "Coded justification for the current status, mandatory for suspension, revocation and termination.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "status-changed-at", "name": "Status changed at", "description": "RFC 3339 instant of the most recent status transition.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-010" ] } ], "artifacts": [ { "id": "role-status-transition-event", "name": "Role status transition event", "description": "An emitted event recording one state change: prior and new status, reason, effective instant, recorded instant and the responsible agent.", "media_or_form": [ "event record", "notification message", "event stream entry" ], "serial": true, "identity_strategy": "Event identifier as UUIDv7 with an RFC 3339 event time and a separately recorded ingestion time; correlates to the assertion identifier and version.", "source_refs": [ "SRC-007", "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "succession-and-acting-holdings", "name": "Succession, handover and acting holdings", "description": "How accountability is carried across a change of holder, whether overlaps or gaps are permitted, and how an interim or deputy holding is distinguished from a substantive one.", "source_refs": [ "SRC-002", "SRC-005", "SRC-007", "SRC-008" ], "questions": [ { "id": "q-succession-chain", "text": "Which assertion succeeds which, and is the succession chain recorded explicitly rather than inferred from dates?", "kind": "relationship", "answer_data": [ "Succeeds and superseded-by references", "Succession kind (appointment, transfer, automatic)", "Chain integrity constraint" ] }, { "id": "q-overlap-or-gap", "text": "Is an overlap or a gap between successive holders permitted for this role type?", "kind": "constraint", "answer_data": [ "Overlap permission rule and maximum overlap", "Gap permission rule and maximum gap", "Detection query and alerting threshold" ] }, { "id": "q-acting-holding", "text": "How is an acting, interim or deputy holding distinguished from a substantive one?", "kind": "classification", "answer_data": [ "Acting flag or distinct role subtype", "Substantive holder reference during the acting period", "Limits that apply only to acting holders" ] }, { "id": "q-gap-accountability", "text": "Who is accountable for acts performed during a coverage gap?", "kind": "authority", "answer_data": [ "Fallback accountable party rule", "Escalation path and notification target", "Record of acts falling in the gap" ] } ], "data_elements": [ { "id": "succeeds-assertion-ref", "name": "Succeeds assertion", "description": "Reference to the assertion this one succeeds in the same position.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "succession-kind", "name": "Succession kind", "description": "How the succession came about.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "acting-flag", "name": "Acting holding flag", "description": "Marks an interim, acting or deputy holding.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-005" ] }, { "id": "handover-at", "name": "Handover instant", "description": "RFC 3339 instant at which accountability passed between holders.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "role-handover-record", "name": "Role handover record", "description": "Record of one handover: outgoing and incoming assertions, handover instant, outstanding matters transferred, acknowledgements and any coverage gap declared.", "media_or_form": [ "handover record", "signed acknowledgement" ], "serial": true, "identity_strategy": "UUIDv7 per handover with RFC 3339 handover and recorded instants; references both assertion identifiers and the position identifier.", "source_refs": [ "SRC-002", "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "authority-and-constraints", "name": "Authority, Delegation and Constraints", "description": "What makes a role assertion authoritative, how authority is passed on, and the rules that limit who may hold what.", "rationale": "GDPR shows that some roles subsist from factual conduct regardless of what a register says, PROV-O and FHIR both model acting-on-behalf-of as a first-class qualified relation, and NIST RBAC contributes separation-of-duty constraints. Authority and constraint are therefore not optional metadata but part of what a role assertion means.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-006", "SRC-008", "SRC-009", "SRC-015" ], "layers": [ { "id": "authority-basis", "name": "Basis of Authority and Mandate", "description": "The ground on which the role subsists and the obligations that attach to it by operation of law or contract.", "source_refs": [ "SRC-004", "SRC-006", "SRC-008", "SRC-009" ], "findings": [ { "id": "basis-of-authority", "name": "Basis of authority and conferring instrument", "description": "Whether the role rests on statute, contract, appointment, court order or self-declaration; which authority conferred it; and whether registration is constitutive of the role or merely declaratory of it.", "source_refs": [ "SRC-004", "SRC-006", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-authority-basis-kind", "text": "On what basis does this role subsist: statute, contract, appointment, court order or self-declaration?", "kind": "authority", "answer_data": [ "Authority basis code", "Reference to the conferring instrument", "Evidence tier required for that basis" ] }, { "id": "q-conferring-authority", "text": "Which authority conferred the role, and is that authority itself identified and within scope?", "kind": "authority", "answer_data": [ "Conferring authority identifier and register", "Scope of the conferring authority's competence", "Rule when the conferring authority is itself a role holder" ] }, { "id": "q-constitutive-or-declaratory", "text": "Does the role subsist as a matter of fact regardless of registration, or does registration constitute it?", "kind": "authority", "answer_data": [ "Constitutive versus declaratory flag per role type", "Consequence of non-registration for a constitutive role", "Handling of a factual role with no corresponding record" ] }, { "id": "q-governing-jurisdiction", "text": "Which jurisdiction's law governs the role, and what applies when jurisdictions conflict?", "kind": "authority", "answer_data": [ "Governing jurisdiction code", "Conflict-of-laws precedence rule adopted by the Dimension", "Cross-border applicability note" ] } ], "data_elements": [ { "id": "authority-basis-kind", "name": "Authority basis kind", "description": "The ground on which the role subsists.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "conferring-authority-ref", "name": "Conferring authority", "description": "Reference to the party or body that conferred the role.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] }, { "id": "mandate-ref", "name": "Mandate or instrument reference", "description": "Reference to the statute, contract, appointment or order that establishes the role.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "constitutive-flag", "name": "Registration constitutive flag", "description": "Whether registration constitutes the role or merely declares a pre-existing fact.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "role-mandate-instrument", "name": "Role mandate instrument", "description": "The instrument that establishes the role: appointment letter, board resolution, contract clause, statutory designation or court order, held or referenced as evidence of authority.", "media_or_form": [ "signed instrument", "document reference", "register citation" ], "serial": false, "identity_strategy": "Identifier issued by the instrument's own register or document management system; otherwise a Dimension-minted UUIDv7 plus a content hash to bind the reference to the exact text relied upon.", "source_refs": [ "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "statutory-role-obligations", "name": "Statutory obligations and factual override", "description": "Some role types carry non-waivable duties and are determined by conduct rather than declaration. GDPR treats an entity as a controller because it determines purposes and means, requires joint controllers to document their allocation of responsibilities, and requires a binding contract for processors.", "source_refs": [ "SRC-003", "SRC-009", "SRC-015" ], "questions": [ { "id": "q-attached-obligations", "text": "Which obligations attach automatically to this role type, and are any of them waivable by agreement?", "kind": "requirement", "answer_data": [ "Obligation references keyed to the role type", "Waivability flag per obligation with legal citation", "Consequence of breach" ] }, { "id": "q-joint-allocation", "text": "How is a jointly held statutory role and the allocation of duties between holders recorded?", "kind": "composition", "answer_data": [ "Joint holding arrangement reference", "Duty allocation per holder", "Designated contact point for affected persons" ] }, { "id": "q-factual-override", "text": "Can factual conduct override a declared role classification, and what triggers reclassification?", "kind": "classification", "answer_data": [ "Factual determination criteria for the role type", "Reclassification trigger and reviewing authority", "Retroactive effect of reclassification on past acts" ] }, { "id": "q-obligation-discharge", "text": "Which evidence demonstrates that the obligations attached to the role were discharged?", "kind": "evidence", "answer_data": [ "Discharge evidence reference per obligation", "Reporting cadence and responsible party", "Retention period for discharge evidence" ] } ], "data_elements": [ { "id": "obligation-ref", "name": "Attached obligation", "description": "Reference to an obligation that attaches to the role type.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-009" ] }, { "id": "obligation-waivable", "name": "Obligation waivability", "description": "Whether the obligation may be varied or waived by agreement.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "duty-allocation", "name": "Duty allocation", "description": "Allocation of specific duties among joint holders of the same role.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "obligation-discharge-ref", "name": "Obligation discharge evidence", "description": "Reference to evidence that an attached obligation was performed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "role-obligation-arrangement", "name": "Role obligation arrangement", "description": "The documented arrangement allocating duties between joint holders, or the binding contract governing a role that acts on another party's behalf, including subject matter, duration, nature and purpose.", "media_or_form": [ "contract or arrangement document", "structured allocation record" ], "serial": false, "identity_strategy": "Contract or arrangement identifier from the owning agreement system; otherwise a Dimension-minted UUIDv7 bound to a content hash of the executed text.", "source_refs": [ "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "eligibility-preconditions-for-occupancy", "name": "Eligibility versus occupancy", "description": "FHIR: qualifications do not imply a Role. HL7 QUAL is recognition that would make an entity an appropriate performer; LIC is scoper-certified authorisation to perform activities under a jurisdiction. Occupancy may require referenced credentials to be valid at event time, but this mixin stores references and expiry checks, not the credential body.", "source_refs": [ "SRC-019", "SRC-021" ], "questions": [ { "id": "eligibility-preconditions-for-occupancy-q01", "text": "Which credentials, licences or qualifications must be valid for this occupancy, and who is the issuing scoper?", "kind": "requirement", "answer_data": [ "required_credential_refs", "issuing_scoper_ref", "check_at_event_time" ] }, { "id": "eligibility-preconditions-for-occupancy-q02", "text": "If a required credential expires while the assignment period is still open, does occupancy auto-suspend?", "kind": "constraint", "answer_data": [ "auto_suspend", "credential_expiry", "suspension_event_id" ] }, { "id": "eligibility-preconditions-for-occupancy-q03", "text": "Is the player eligible but not occupying, and should eligibility be recorded only on the credential sibling?", "kind": "decision", "answer_data": [ "eligible_unassigned", "credential_sibling_ref" ] } ], "data_elements": [ { "id": "eligibility-preconditions-for-occupancy-data01", "name": "Required credential reference", "description": "Credential or licence that must be valid during occupancy.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-021" ] }, { "id": "eligibility-preconditions-for-occupancy-data02", "name": "Auto-suspend on credential expiry", "description": "Whether occupancy suspends when a required credential expires.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "Eligibility is a set of references to a credential sibling plus inline policy flags." } ] }, { "id": "delegation-and-representation", "name": "Delegation and Representation", "description": "Chains of acting on behalf of another, and the limits on what a role holder may bind.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-006", "SRC-008", "SRC-009", "SRC-015" ], "findings": [ { "id": "delegation-and-on-behalf-of", "name": "Delegation and acting on behalf of", "description": "PROV-O reifies delegation as prov:Delegation qualifying prov:actedOnBehalfOf, and FHIR constrains agent.who to differ from agent.onBehalfOf. The mixin carries the delegator, the chain, sub-delegation permission and revocation.", "source_refs": [ "SRC-001", "SRC-004", "SRC-006", "SRC-009" ], "questions": [ { "id": "q-delegator", "text": "Who delegated the authority for this holding, and is the delegator itself a recorded role holder?", "kind": "authority", "answer_data": [ "On-behalf-of party reference", "Delegator's own assertion reference", "Validation that the delegator held the authority delegated" ] }, { "id": "q-chain-depth", "text": "How deep may a delegation chain go, and is sub-delegation permitted?", "kind": "constraint", "answer_data": [ "Maximum chain depth and cycle prohibition", "Sub-delegation permission flag per role type", "Notification duty on sub-delegation" ] }, { "id": "q-delegation-revocation", "text": "How is a delegation revoked, and what is the effect on acts already performed under it?", "kind": "lifecycle", "answer_data": [ "Revocation instant and reason", "Prospective versus retroactive effect rule", "Ratification path for acts in the revocation window" ] }, { "id": "q-distinct-parties", "text": "Must the delegate and the delegator be distinct parties, and how is that enforced?", "kind": "validation", "answer_data": [ "Distinctness constraint identifier", "Enforcement point and failure code", "Documented exceptions such as self-appointment by sole officers" ] } ], "data_elements": [ { "id": "on-behalf-of-ref", "name": "On behalf of", "description": "The party on whose behalf the holder exercises the role.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-006", "SRC-009" ] }, { "id": "delegation-chain-depth", "name": "Delegation chain depth", "description": "Number of delegation hops from the original authority to this holder.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "sub-delegation-permitted", "name": "Sub-delegation permitted", "description": "Whether the holder may delegate onward.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-009" ] }, { "id": "delegation-revoked-at", "name": "Delegation revoked at", "description": "RFC 3339 instant at which the delegation was revoked.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-010" ] } ], "artifacts": [ { "id": "delegation-instrument", "name": "Delegation instrument", "description": "The record of one delegation: delegator, delegate, scope of delegated authority, limits, permitted sub-delegation, validity period and revocation state.", "media_or_form": [ "delegation record", "power of attorney or mandate document", "verifiable credential" ], "serial": false, "identity_strategy": "Identifier from the issuing register or credential system where one exists; otherwise a Dimension-minted UUIDv7 with an RFC 3339 issuance instant and a status endpoint for revocation.", "source_refs": [ "SRC-001", "SRC-004", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "representation-and-limits", "name": "Representation limits and joint action", "description": "What a holder may bind the host or scoping party to, expressed as machine-checkable limits rather than prose, and how this differs from system permissions.", "source_refs": [ "SRC-003", "SRC-008", "SRC-009", "SRC-015" ], "questions": [ { "id": "q-binding-limit", "text": "What may the holder of this role commit the host or scoping party to, and up to what limit?", "kind": "constraint", "answer_data": [ "Limit value with unit and currency", "Categories of commitment covered and excluded", "Limit review cadence" ] }, { "id": "q-joint-action", "text": "Is joint or countersigned action required, and what quorum applies?", "kind": "constraint", "answer_data": [ "Joint action requirement flag", "Quorum expression (number or proportion of holders)", "Permitted counterpart role types" ] }, { "id": "q-machine-checkable", "text": "How are representation limits expressed so a system can check them rather than a human reading prose?", "kind": "validation", "answer_data": [ "Constraint expression language and its version", "Evaluation point in the process", "Fallback when a limit cannot be evaluated" ] }, { "id": "q-representation-vs-permission", "text": "How does representation authority differ from the system permissions granted to the holder?", "kind": "security", "answer_data": [ "Explicit statement that the role carries no permissions", "Reference to the authorization model that consumes the role", "Reconciliation check between conferred authority and granted permissions" ] } ], "data_elements": [ { "id": "representation-limit", "name": "Representation limit", "description": "Maximum commitment the holder may make on behalf of the host or scoping party.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "quorum-requirement", "name": "Quorum requirement", "description": "Number or proportion of holders whose concurrence is required for a valid act.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "constraint-expression", "name": "Machine-checkable constraint expression", "description": "Formal expression of the limit, evaluable by a policy engine.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "joint-action-required", "name": "Joint action required", "description": "Whether acts under this role require countersignature.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "representation-authority-schedule", "name": "Representation authority schedule", "description": "The schedule of representation limits, quorum rules and excluded categories attaching to a role type or position, published as the authoritative reference for downstream checks.", "media_or_form": [ "schedule document", "machine-readable policy set" ], "serial": false, "identity_strategy": "Governed schedule IRI with immutable version and RFC 3339 effective-from instant; bound to role type and position identifiers.", "source_refs": [ "SRC-003", "SRC-009", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "ultimate-and-immediate-party", "name": "On-behalf-of and ultimate party", "description": "PROV actedOnBehalfOf and qualified Delegation record that an agent acted for another. FHIR Provenance.agent.onBehalfOf is the delegating agent and must not equal who. ISO 20022 distinguishes Debtor/Creditor from UltimateDebtor/UltimateCreditor for payments on behalf of another. UN/CEFACT distinguishes direct and indirect representation. Chains must be explicit.", "source_refs": [ "SRC-018", "SRC-020", "SRC-022", "SRC-024" ], "questions": [ { "id": "ultimate-and-immediate-party-q01", "text": "On whose behalf is this player occupying the role, and is that party different from the player?", "kind": "relationship", "answer_data": [ "on_behalf_of_ref", "player_ref", "same_party_forbidden" ] }, { "id": "ultimate-and-immediate-party-q02", "text": "Who is the ultimate party versus the immediate party in this agency chain?", "kind": "relationship", "answer_data": [ "ultimate_party_ref", "immediate_party_ref", "chain_length" ] }, { "id": "ultimate-and-immediate-party-q03", "text": "Is representation direct or indirect, as in UN/CEFACT DEN/DEO, and what instrument authorises it?", "kind": "authority", "answer_data": [ "representation_mode", "authorising_instrument_ref" ] }, { "id": "ultimate-and-immediate-party-q04", "text": "What plan, mandate or power-of-attorney, if any, did the agent follow (PROV hadPlan)?", "kind": "composition", "answer_data": [ "plan_ref", "mandate_ref" ] } ], "data_elements": [ { "id": "ultimate-and-immediate-party-data01", "name": "On-behalf-of reference", "description": "Party or agent that delegated authority to the player.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-024" ] }, { "id": "ultimate-and-immediate-party-data02", "name": "Ultimate party reference", "description": "Ultimate originator or beneficiary when different from the immediate player.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "ultimate-and-immediate-party-data03", "name": "Representation mode", "description": "direct, indirect, or unspecified representation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020" ] }, { "id": "ultimate-and-immediate-party-data04", "name": "Plan or mandate reference", "description": "Plan, mandate or instrument the agent intended to follow.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "ultimate-and-immediate-party-artifact01", "name": "Delegation or representation instrument", "description": "Power of attorney, mandate, agency agreement or PROV Plan that authorises on-behalf-of occupancy.", "media_or_form": [ "legal-instrument", "plan", "binary" ], "serial": true, "identity_strategy": "Instrument identifier from the issuing authority if present; otherwise hash-backed Dimension identifier.", "source_refs": [ "SRC-018", "SRC-020", "SRC-024" ] } ], "inline_only_rationale": null } ] }, { "id": "multiplicity-and-separation", "name": "Multiplicity and Separation of Duties", "description": "How many holders a role admits, and which role combinations are forbidden for the same party.", "source_refs": [ "SRC-002", "SRC-005", "SRC-006", "SRC-007", "SRC-009", "SRC-013", "SRC-015" ], "findings": [ { "id": "role-multiplicity", "name": "Multiplicity, exclusivity and mandatory roles", "description": "Cardinality constraints on the assertion: how many parties may hold a role on a host, whether the same party may hold it more than once with different qualifiers, and whether the host is invalid without the role filled.", "source_refs": [ "SRC-002", "SRC-005", "SRC-007", "SRC-009", "SRC-013" ], "questions": [ { "id": "q-holder-cardinality", "text": "How many parties may simultaneously hold this role on the same host?", "kind": "constraint", "answer_data": [ "Minimum and maximum holder counts per role type and host kind", "Enforcement point and violation code", "Whether the maximum is per-instant or per-period" ] }, { "id": "q-repeat-holding", "text": "May one party hold the same role on the same host more than once with different qualifiers?", "kind": "constraint", "answer_data": [ "Uniqueness key including qualifier dimensions", "Permitted repeat scenarios", "Deduplication behaviour on violation" ] }, { "id": "q-mandatory-role", "text": "Is this role mandatory for the host, and what validates that it is filled?", "kind": "requirement", "answer_data": [ "Mandatory-role rule per host kind", "Validation check and the state a host enters when unfilled", "Grace period before escalation" ] }, { "id": "q-share-summation", "text": "How are joint holders' shares or ranks expressed, and must they sum to a declared total?", "kind": "measurement", "answer_data": [ "Share or rank per holder with unit", "Summation constraint and tolerance", "Handling of unallocated remainder" ] } ], "data_elements": [ { "id": "holder-cardinality", "name": "Holder cardinality bounds", "description": "Minimum and maximum simultaneous holders permitted for the role on a host.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-009" ] }, { "id": "assertion-uniqueness-key", "name": "Assertion uniqueness key", "description": "Attribute set over which duplicate assertions are prohibited.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-007" ] }, { "id": "holder-share", "name": "Holder share or rank", "description": "Proportional share or ordinal rank of a joint holder.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "role-mandatory-on-host", "name": "Role mandatory on host", "description": "Whether the host is incomplete or invalid while the role is unfilled.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "role-cardinality-constraint-set", "name": "Role cardinality constraint set", "description": "Machine-evaluable constraints stating, per role type and host kind, holder bounds, uniqueness keys, mandatory-role rules and share summation requirements.", "media_or_form": [ "constraint set", "validation profile" ], "serial": false, "identity_strategy": "Governed constraint set IRI with immutable version and RFC 3339 effective-from instant.", "source_refs": [ "SRC-005", "SRC-007", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "segregation-and-conflict", "name": "Segregation of duties and conflict of interest", "description": "Incompatible role pairs, static versus per-transaction exclusion, time-limited exceptions, and declared conflicts of interest. NIST RBAC contributes the static and dynamic separation-of-duty distinction; FHIR contributes the concrete who-is-not-onBehalfOf constraint.", "source_refs": [ "SRC-006", "SRC-009", "SRC-013", "SRC-015" ], "questions": [ { "id": "q-incompatible-pairs", "text": "Which role pairs are mutually exclusive for the same party on the same host, and is the exclusion static or evaluated per transaction?", "kind": "constraint", "answer_data": [ "Incompatible role pair list with scope", "Separation mode (static or dynamic/per-transaction)", "Evaluation point and denial code" ] }, { "id": "q-sod-exception", "text": "How is an approved exception to a segregation rule recorded, justified and time-limited?", "kind": "exception", "answer_data": [ "Exception approval reference and approving authority", "Expiry instant and compensating control", "Review cadence while the exception is open" ] }, { "id": "q-conflict-declaration", "text": "How are conflicts of interest declared by holders, and who adjudicates them?", "kind": "decision", "answer_data": [ "Declaration record and its cadence", "Adjudicating body and decision outcome codes", "Consequence for the affected assertion" ] }, { "id": "q-new-rule-backfill", "text": "What must happen to existing assertions when a new segregation rule is introduced?", "kind": "lifecycle", "answer_data": [ "Backfill scan procedure and its schedule", "Grandfathering policy and its justification", "Remediation deadline per violation severity" ] } ], "data_elements": [ { "id": "incompatible-role-pair", "name": "Incompatible role pair", "description": "A pair of role types that may not be held by the same party within a declared scope.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "separation-mode", "name": "Separation mode", "description": "Whether exclusion is enforced at assignment time or at transaction time.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "sod-exception-ref", "name": "Segregation exception reference", "description": "Reference to an approved, time-limited exception permitting an otherwise forbidden combination.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "conflict-declaration-ref", "name": "Conflict declaration reference", "description": "Reference to a declared conflict of interest affecting the holding.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-013" ] } ], "artifacts": [ { "id": "segregation-ruleset", "name": "Segregation of duties ruleset", "description": "The governed set of incompatible role combinations, their separation mode, scope and severity, versioned so that historical enforcement decisions can be reconstructed.", "media_or_form": [ "ruleset", "policy release" ], "serial": false, "identity_strategy": "Governed ruleset IRI with immutable version and RFC 3339 effective-from instant.", "source_refs": [ "SRC-015" ] }, { "id": "conflict-of-interest-declaration", "name": "Conflict of interest declaration", "description": "A dated declaration by or about a role holder describing a potential conflict, the adjudication outcome and any mitigation imposed.", "media_or_form": [ "declaration record", "signed statement" ], "serial": true, "identity_strategy": "UUIDv7 per declaration with RFC 3339 declaration and recorded instants; references the holder and the affected assertions.", "source_refs": [ "SRC-009", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "provenance-evidence-quality", "name": "Provenance, Evidence and Quality", "description": "Who says this role holds, on what evidence, at what level of corroboration, and what happens when the claim is contested.", "rationale": "A role assertion is a claim about the world made by someone. GLEIF operationalises exactly this with four validation source levels and typed validation documents; PROV-O and FHIR Provenance supply the pattern for recording who asserted what and when; W3C VC supplies revocable evidence. Without this bundle the mixin cannot be audited.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-009" ], "layers": [ { "id": "assertion-provenance", "name": "Assertion Provenance", "description": "Provenance of the claim itself, kept strictly separate from provenance of the host.", "source_refs": [ "SRC-001", "SRC-004", "SRC-006", "SRC-008" ], "findings": [ { "id": "who-asserted-and-ownership", "name": "Asserting agent, source system and record ownership", "description": "The agent that made the assertion, the role that agent acted in, the system and record it came from, whether the claim is first-, second- or third-party, and who owns and may change the record.", "source_refs": [ "SRC-001", "SRC-004", "SRC-006", "SRC-008" ], "questions": [ { "id": "q-asserting-agent", "text": "Which agent asserted this role assertion, and in what role did that agent act when asserting it?", "kind": "provenance", "answer_data": [ "Asserting agent reference", "Role of the asserting agent, itself a Party Role assertion", "Plan or procedure followed when asserting" ] }, { "id": "q-source-system", "text": "Which source system, source record and extraction process produced the assertion?", "kind": "provenance", "answer_data": [ "Source system identifier and record reference", "Extraction or transformation process identifier and version", "Ingestion instant distinct from the source's own recorded instant" ] }, { "id": "q-party-tier", "text": "Is the assertion first-party self-declared by the player, second-party from the counterparty, or third-party from an independent source?", "kind": "provenance", "answer_data": [ "Assertion party tier code", "Independence assessment of the source", "Weighting applied to the tier in conflict resolution" ] }, { "id": "q-record-ownership", "text": "Who owns and maintains this role assertion record, and who is permitted to change it?", "kind": "ownership", "answer_data": [ "Record owner reference and accountable role", "Permitted mutating roles and their scope", "Escalation path when the owner is unavailable or in conflict" ] } ], "data_elements": [ { "id": "asserted-by-ref", "name": "Asserted by", "description": "Agent that made the assertion.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "asserting-agent-role", "name": "Asserting agent role", "description": "The role in which the asserting agent acted, recorded as its own assertion reference.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "source-record-ref", "name": "Source system and record", "description": "Identifier of the originating system and the record within it.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "assertion-party-tier", "name": "Assertion party tier", "description": "Whether the claim is first-, second- or third-party.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "record-owner-ref", "name": "Record owner", "description": "Party accountable for maintaining the assertion record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "assertion-provenance-bundle", "name": "Role assertion provenance bundle", "description": "A bundle recording the agents, activities, plans and source entities behind one or more assertions, expressed with the qualified-relation pattern so that roles of the asserting agents are themselves explicit.", "media_or_form": [ "provenance bundle", "graph serialization", "audit package" ], "serial": false, "identity_strategy": "Bundle IRI minted in the Dimension namespace; carries a content hash and an RFC 3339 generation instant separate from the instants of the events it describes.", "source_refs": [ "SRC-001", "SRC-006", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "evidence-and-quality", "name": "Evidence, Verification and Quality", "description": "Documents and credentials substantiating the role, the corroboration level reached, and how contested or erroneous assertions are handled.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-009" ], "findings": [ { "id": "evidence-and-verification", "name": "Supporting evidence and the verification act", "description": "GLEIF grades validation from entity-supplied-only to fully corroborated and types the validation documents used; W3C VC makes evidence revocable and time-bounded; FHIR warns that a qualification held by a practitioner does not by itself imply a role.", "source_refs": [ "SRC-004", "SRC-005", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-evidence-reference", "text": "Which document or credential evidences this role, and is it held or only referenced?", "kind": "evidence", "answer_data": [ "Evidence reference and evidence kind", "Held-versus-referenced flag and storage location", "Content hash binding the reference to the exact evidence relied upon" ] }, { "id": "q-corroboration-level", "text": "What corroboration level applies to this assertion?", "kind": "quality", "answer_data": [ "Corroboration level from a graded scale", "Sources consulted to reach that level", "Minimum level required before publication" ] }, { "id": "q-verification-process", "text": "What process must be completed before an asserted role is treated as verified?", "kind": "process", "answer_data": [ "Verification procedure identifier and steps", "Verifier role and independence requirement", "Outcome codes and re-work path on failure" ] }, { "id": "q-qualification-implication", "text": "Does a licence or qualification held by the player imply this role, or must the role be asserted separately?", "kind": "classification", "answer_data": [ "Explicit non-implication rule", "Eligibility versus holding distinction", "Cases where a licence is a precondition but not a role" ] } ], "data_elements": [ { "id": "evidence-ref", "name": "Evidence reference", "description": "Reference to a document or credential substantiating the role.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "corroboration-level", "name": "Corroboration level", "description": "Graded assessment of how independently the assertion is supported.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "verified-at", "name": "Verified at", "description": "RFC 3339 instant of the most recent successful verification.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] }, { "id": "evidence-expires-at", "name": "Evidence expiry", "description": "Instant at which the supporting evidence ceases to be valid.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-010" ] }, { "id": "verified-by-ref", "name": "Verified by", "description": "Party that performed the verification.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "role-verification-report", "name": "Role verification report", "description": "The dated outcome of one verification exercise: assertions examined, evidence consulted, corroboration level reached, exceptions raised and the verifier.", "media_or_form": [ "report record", "signed attestation" ], "serial": true, "identity_strategy": "UUIDv7 per report with RFC 3339 verification and issuance instants; references the assertion identifiers and evidence hashes examined.", "source_refs": [ "SRC-004", "SRC-008", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "quality-and-dispute", "name": "Assertion quality, dispute and annulment", "description": "Confidence measures, representation of a contested claim while the dispute is open, and the distinction between an assertion that has ended and one that was never true.", "source_refs": [ "SRC-004", "SRC-006", "SRC-007", "SRC-008" ], "questions": [ { "id": "q-quality-score", "text": "What confidence or data-quality measure attaches to this assertion, and how is it computed?", "kind": "quality", "answer_data": [ "Quality measure value and scale", "Computation inputs including corroboration level and staleness", "Recomputation trigger and cadence" ] }, { "id": "q-dispute-open", "text": "How is a disputed or challenged assertion represented while the dispute remains open?", "kind": "exception", "answer_data": [ "Dispute status value distinct from suspension", "Disputing party and grounds", "Whether the assertion remains visible and actionable during dispute" ] }, { "id": "q-annulment", "text": "How is an assertion that was never true distinguished from one that has legitimately ended?", "kind": "state", "answer_data": [ "Annulled status distinct from ended status", "Effect of annulment on downstream derived assertions", "Notification duty to prior recipients" ] }, { "id": "q-staleness-trigger", "text": "What triggers automatic re-validation or lapse of an unverified assertion?", "kind": "validation", "answer_data": [ "Staleness threshold per role type", "Automatic action on breach (flag, lapse, suppress)", "Owner notification and remediation window" ] } ], "data_elements": [ { "id": "quality-measure", "name": "Assertion quality measure", "description": "Computed confidence or completeness measure for the assertion.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "dispute-status", "name": "Dispute status", "description": "Whether the assertion is challenged and by whom.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "annulled-flag", "name": "Annulled flag", "description": "Marks an assertion determined never to have been true, as distinct from one that has ended.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "revalidation-due-at", "name": "Revalidation due at", "description": "Instant by which the assertion must be re-verified before it is treated as stale.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Quality measures, dispute status and annulment are inline state on the assertion and its version history; the dispute lifecycle is already carried by the status transition event and version history artifacts, and minting a third artifact would fragment the audit trail across records that could disagree." } ] } ] }, { "id": "governance-access-retention", "name": "Disclosure, Access and Retention", "description": "Who may see a role assertion, on what basis, and how long role history survives erasure pressure without breaking accountability chains.", "rationale": "A role assertion about a natural person is personal data and is frequently published (registers of directors, contributor lists, provider directories). GDPR supplies the recipient and third-party concepts and the storage limitation and erasure duties; W3C VC supplies selective disclosure; GLEIF shows durable retirement rather than deletion.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-006", "SRC-008", "SRC-009" ], "layers": [ { "id": "disclosure-and-privacy", "name": "Disclosure and Privacy", "description": "Publication tiers, minimization, role-only disclosure and recipient logging.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-009" ], "findings": [ { "id": "disclosure-tiers-and-minimization", "name": "Disclosure tiers, minimization and recipient logging", "description": "Which parts of an assertion may be published, which are restricted, whether the role can be disclosed without disclosing the holder, and which recipients have received it.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-009" ], "questions": [ { "id": "q-disclosure-tier", "text": "Which parts of a role assertion may be published, and which are restricted to named recipients?", "kind": "access", "answer_data": [ "Field-level disclosure tier assignments", "Public projection profile listing publishable fields", "Approval required to move a field to a wider tier" ] }, { "id": "q-disclosure-basis", "text": "What is the legal basis for disclosing a natural person's role assertion, and which model holds that basis?", "kind": "privacy", "answer_data": [ "Legal basis reference held in the consent or lawful-basis model", "Statutory publication duty citation where one applies", "Objection handling path for the holder" ] }, { "id": "q-role-only-disclosure", "text": "Can the role be disclosed without disclosing the holder's identity?", "kind": "privacy", "answer_data": [ "Role-only projection definition", "Re-identification risk assessment for small populations", "Conditions requiring identity disclosure despite the default" ] }, { "id": "q-recipient-log", "text": "Which recipients have received this assertion, and is each disclosure itself recorded?", "kind": "access", "answer_data": [ "Recipient reference and disclosure instant", "Purpose of disclosure and the field set disclosed", "Retention period for the disclosure record" ] } ], "data_elements": [ { "id": "disclosure-tier", "name": "Disclosure tier", "description": "Field-level or record-level classification governing who may see the data.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "legal-basis-ref", "name": "Legal basis reference", "description": "Reference to the lawful basis or statutory duty relied upon for disclosure.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "minimized-projection-ref", "name": "Minimized projection profile", "description": "Named projection listing exactly the fields released at a given tier.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] }, { "id": "recipient-ref", "name": "Recipient", "description": "Party to which the assertion or a projection of it was disclosed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "disclosure-decision-log", "name": "Disclosure decision log", "description": "Log of disclosure decisions and actual disclosures: recipient, purpose, basis, field set, tier and instant, sufficient to answer a subject access or recipient-notification request.", "media_or_form": [ "append-only log", "access audit extract" ], "serial": true, "identity_strategy": "UUIDv7 per entry with RFC 3339 disclosure and recorded instants; references the assertion identifier, the projection profile and the recipient identifier.", "source_refs": [ "SRC-009", "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "retention-and-erasure", "name": "Retention, Erasure and Tombstones", "description": "How long ended role history is kept, and how erasure is reconciled with accountability chains that depend on it.", "source_refs": [ "SRC-004", "SRC-006", "SRC-008", "SRC-009" ], "findings": [ { "id": "retention-erasure-tombstones", "name": "Retention classes, tombstones and legal hold", "description": "Ended roles are the backbone of historical accountability, so deletion cannot be unconditional. The model requires a retention class, a tombstone that preserves referential integrity when content is erased, and an explicit legal hold mechanism.", "source_refs": [ "SRC-004", "SRC-006", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-retention-class", "text": "How long must an ended role assertion be retained, and on whose authority is that period set?", "kind": "retention", "answer_data": [ "Retention class and computed retain-until instant", "Authority for the period (statute, contract, internal schedule)", "Trigger event from which the period runs" ] }, { "id": "q-tombstone", "text": "When an erasure request is honoured, what tombstone remains so accountability chains do not break?", "kind": "retention", "answer_data": [ "Tombstone field set retained (identifier, role type, period, status)", "Fields erased or irreversibly redacted", "Effect on assertions that reference the erased record" ] }, { "id": "q-hard-delete", "text": "Is hard deletion of a role assertion ever permitted, and what is the escalation path?", "kind": "exception", "answer_data": [ "Conditions permitting hard delete", "Dual-authorization requirement and approvers", "Record of the deletion that itself survives" ] }, { "id": "q-legal-hold", "text": "How is a legal hold applied to role history and subsequently released?", "kind": "authority", "answer_data": [ "Legal hold flag with the imposing authority and matter reference", "Suspension of retention timers while held", "Release procedure and its record" ] } ], "data_elements": [ { "id": "retention-class", "name": "Retention class", "description": "Retention rule applied to the assertion and its history.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "retain-until", "name": "Retain until", "description": "RFC 3339 instant until which the record must be preserved.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "tombstone-record", "name": "Tombstone record", "description": "Minimal surviving record preserving identifier, role type, period and status after content erasure.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-008" ] }, { "id": "legal-hold-flag", "name": "Legal hold", "description": "Indicates retention timers are suspended by an imposed hold.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "retention-disposition-log", "name": "Retention and disposition log", "description": "Record of retention decisions, erasure requests, redactions, tombstone creation, legal holds and releases, retained beyond the records it describes.", "media_or_form": [ "append-only log", "disposition certificate" ], "serial": true, "identity_strategy": "UUIDv7 per entry with RFC 3339 action and recorded instants; references the assertion identifier which survives in the tombstone.", "source_refs": [ "SRC-009", "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "interoperability-and-projection", "name": "Interoperability and Projection", "description": "How the mixin maps onto external role constructs, where those constructs conflict, and what must survive any projection.", "rationale": "Rule 8 requires external standards to be treated as alignments rather than conformance claims, and the reviewed standards genuinely disagree: PROV-O restricts hadRole to activity associations, org restricts Membership to organizations, and RBAC uses the same word for a different thing. Those conflicts must be recorded, not smoothed over.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-005", "SRC-006", "SRC-007", "SRC-010", "SRC-011", "SRC-012", "SRC-013", "SRC-014", "SRC-015", "SRC-017" ], "layers": [ { "id": "external-alignment", "name": "External Standard Alignment", "description": "Mapping to external role constructs with explicit relation strength, and the register of known conflicts.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-005", "SRC-006", "SRC-012", "SRC-013", "SRC-014", "SRC-015", "SRC-017" ], "findings": [ { "id": "alignment-and-conflicts", "name": "Alignment mappings, conflicts and conformance claims", "description": "Each external target is mapped with an explicit relation (exact, broader, narrower, related) and the mapping evidence is recorded. Conflicts are registered rather than resolved by assertion, and no conformance is claimed without evidence.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-005", "SRC-006", "SRC-012", "SRC-013", "SRC-014", "SRC-015", "SRC-017" ], "questions": [ { "id": "q-alignment-relation", "text": "Which external construct does this assertion or role type map to, and is the mapping exact, broader, narrower or merely related?", "kind": "interoperability", "answer_data": [ "Target construct IRI with standard name and version", "Mapping relation code", "Evidence supporting the mapping and its reviewer" ] }, { "id": "q-activity-only-restriction", "text": "Where an external standard restricts roles to activity associations, how is an object-scoped role expressed without misusing that standard?", "kind": "interoperability", "answer_data": [ "Substitute construct used for object-scoped roles", "Explicit note that the direct property is not reused", "Round-trip test showing no false conformance" ] }, { "id": "q-conflict-precedence", "text": "Which conflicts between aligned standards are known, and which interpretation prevails in this Dimension?", "kind": "decision", "answer_data": [ "Conflict register entries with the standards in tension", "Precedence decision and its rationale", "Decision date and reviewing authority" ] }, { "id": "q-conformance-evidence", "text": "What evidence supports any claim of conformance to an aligned standard?", "kind": "evidence", "answer_data": [ "Conformance claim status (aligned, partially conformant, conformant, none)", "Test suite or review evidence reference", "Explicit statement where no conformance is claimed" ] } ], "data_elements": [ { "id": "alignment-target", "name": "Alignment target", "description": "IRI and version of the external construct being mapped to.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-012" ] }, { "id": "alignment-relation", "name": "Alignment relation", "description": "Strength of the mapping between the local construct and the external one.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-017" ] }, { "id": "conflict-note", "name": "Conflict note", "description": "Recorded disagreement between aligned standards and the precedence decision taken.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-015" ] }, { "id": "conformance-claim-status", "name": "Conformance claim status", "description": "Whether conformance is claimed, and at what level, with supporting evidence.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] } ], "artifacts": [ { "id": "role-alignment-crosswalk", "name": "Role alignment crosswalk", "description": "A published crosswalk between local role types and external vocabularies and constructs, with relation strength, evidence, conflict notes and conformance status per target.", "media_or_form": [ "crosswalk table", "mapping set", "concept mapping release" ], "serial": true, "identity_strategy": "Governed crosswalk IRI with immutable version identifier and RFC 3339 publication instant; each row cites the source vocabulary version it was mapped against.", "source_refs": [ "SRC-013", "SRC-014", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "participation-vs-standing-role", "name": "Participation versus role boundary", "description": "Standing Party Role occupancy is not a statement that the player performed a particular act. FHIR Provenance.agent.type records how an agent participated in an activity; PractitionerRole records what the practitioner may perform for an organisation over a period. ISO 20022 PartyRole on a Payment is activity-instance scoped and should be linked as participation-like use of this mixin, not stored as a second identity model.", "source_refs": [ "SRC-019", "SRC-022", "SRC-024" ], "questions": [ { "id": "participation-vs-standing-role-q01", "text": "Is this record a standing assignment or an activity-instance participation, and which sibling holds the other?", "kind": "classification", "answer_data": [ "assignment_mode", "participation_ref", "standing_assignment_ref" ] }, { "id": "participation-vs-standing-role-q02", "text": "If linked to a participation, what participation type (performer, author, enterer, verifier) applies to the activity?", "kind": "relationship", "answer_data": [ "participation_type", "activity_ref" ] }, { "id": "participation-vs-standing-role-q03", "text": "Does this Dimension forbid merging standing occupancy and act-participation into a single undifferentiated role record?", "kind": "constraint", "answer_data": [ "merge_forbidden", "policy_uri" ] } ], "data_elements": [ { "id": "participation-vs-standing-role-data01", "name": "Assignment mode", "description": "standing-assignment or activity-instance.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-024" ] }, { "id": "participation-vs-standing-role-data02", "name": "Participation reference", "description": "Optional link to a participation sibling for a specific activity.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-024" ] } ], "artifacts": [], "inline_only_rationale": "The participation boundary is a mode flag plus a sibling reference." } ] }, { "id": "projection-and-exchange", "name": "Projection and Exchange Invariants", "description": "What must hold in every serialization and interface so that the same assertion is recognisable across projections.", "source_refs": [ "SRC-001", "SRC-007", "SRC-010", "SRC-011", "SRC-012" ], "findings": [ { "id": "projection-invariants", "name": "Projection invariants and canonical form", "description": "Fields that are semantically load-bearing must survive every projection; conveniences such as hyperlinks and denormalized labels must be marked projection-local. A canonical form is required for hashing and change detection.", "source_refs": [ "SRC-001", "SRC-007", "SRC-010", "SRC-011", "SRC-012" ], "questions": [ { "id": "q-invariant-fields", "text": "Which fields are invariant across every projection, and which exist only within a particular projection?", "kind": "interoperability", "answer_data": [ "Invariant field list", "Projection-local field list with the projection that owns each", "Rule forbidding semantics carried only in a projection-local field" ] }, { "id": "q-canonical-form", "text": "What canonical serialization is used for hashing and change detection?", "kind": "validation", "answer_data": [ "Canonicalization algorithm and version", "Field ordering, normalization and absent-versus-null rules", "Hash algorithm and where the digest is recorded" ] }, { "id": "q-reference-resolution", "text": "How are references expressed so they resolve in both a graph projection and a document or tabular projection?", "kind": "interoperability", "answer_data": [ "Reference form carrying identifier and scheme independently of any URL", "Resolution service contract", "Rule that a dereferenceable link never replaces the identifier" ] }, { "id": "q-partial-projection", "text": "How is a filtered or partial projection marked so consumers do not treat it as complete?", "kind": "quality", "answer_data": [ "Completeness flag and the filter applied", "Projection profile identifier accompanying the payload", "Consumer obligation when completeness is false" ] } ], "data_elements": [ { "id": "canonical-form-id", "name": "Canonical form identifier", "description": "Identifier and version of the canonicalization rules applied.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-011" ] }, { "id": "content-hash", "name": "Content hash", "description": "Digest over the canonical form, used for change detection and integrity.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "projection-profile-id", "name": "Projection profile identifier", "description": "Named profile describing which fields a given projection carries.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "completeness-flag", "name": "Completeness flag", "description": "Whether the payload is a complete representation or a filtered subset.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "canonical-projection-profile", "name": "Canonical projection profile", "description": "The specification of canonical form, invariant field set and each supported projection's field mapping, used to validate that any storage or interface projection preserves the model's semantics.", "media_or_form": [ "profile specification", "schema mapping set" ], "serial": false, "identity_strategy": "Governed profile IRI with immutable version and RFC 3339 effective-from instant; each supported projection is named and versioned within it.", "source_refs": [ "SRC-007", "SRC-010", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "assert-party-role", "name": "Assert a party role", "description": "Create a new role assertion binding a player to a host with a role type, validity and authority basis.", "inputs": [ "Player reference or explicit vacancy marker", "Host reference and host kind", "Role type term with vocabulary version", "Valid-from instant and optional valid-until", "Authority basis and mandate reference", "Asserting agent identity" ], "outputs": [ "Persisted role assertion with a governing identifier", "Create event", "Validation report" ], "preconditions": [ "Host reference resolves under the declared reference mode", "Role type exists and is active in the bound vocabulary version", "Player kind is admissible for the role type, or vacancy is permitted", "Cardinality and segregation constraints pass" ], "effects": [ "A new assertion identifier is allocated per the identity priority", "recorded-at is set from the register clock, distinct from valid-from", "A create event is emitted to subscribers" ], "source_refs": [ "SRC-005", "SRC-007", "SRC-010", "SRC-011" ] }, { "id": "resolve-role-holders-at-time", "name": "Resolve role holders as of a time", "description": "Answer who held a given role on a given host at a given effective time, optionally as the register knew it at a second time.", "inputs": [ "Host reference", "Role type or role type set", "Effective instant", "Optional knowledge instant for bitemporal replay", "Optional qualifier filter" ], "outputs": [ "Ordered set of matching assertions with holders and qualifiers", "Completeness flag and applied filter", "Derived-holding indicators where cascade rules applied" ], "preconditions": [ "Bitemporal index is available for the requested knowledge instant", "Caller is authorized for the requested disclosure tier" ], "effects": [ "A read access record is written where the disclosure tier requires it", "No assertion state is modified" ], "source_refs": [ "SRC-006", "SRC-008", "SRC-010" ] }, { "id": "resolve-roles-of-party", "name": "Resolve roles held by a party", "description": "Return the roles a party holds or held across hosts, respecting cascade rules and disclosure tiers.", "inputs": [ "Player reference", "Optional host kind or role type filter", "Effective interval", "Requested disclosure tier" ], "outputs": [ "Assertions grouped by host with direct and derived flags", "Conflict and segregation warnings across the returned set", "Minimized projection where the tier requires it" ], "preconditions": [ "Player reference resolves or has a retained alias", "Caller authorization covers every host in the result set" ], "effects": [ "Results are filtered rather than truncated silently, with the filter declared", "A disclosure log entry is written for restricted tiers" ], "source_refs": [ "SRC-005", "SRC-007", "SRC-009" ] }, { "id": "validate-role-assertion", "name": "Validate a role assertion", "description": "Check an assertion against well-formedness, vocabulary binding, temporal, cardinality, segregation and representation constraints.", "inputs": [ "Candidate or persisted assertion", "Applicable vocabulary release, constraint set, segregation ruleset and scope profile" ], "outputs": [ "Pass or fail outcome with per-rule results", "Machine-readable violation codes and severities", "Remediation guidance per violation" ], "preconditions": [ "All referenced rule artifacts are resolvable at their pinned versions" ], "effects": [ "Validation outcome and the rule-artifact versions used are recorded on the assertion version", "Severe violations block publication of the assertion" ], "source_refs": [ "SRC-005", "SRC-009", "SRC-015" ] }, { "id": "transition-role-status", "name": "Transition role status", "description": "Move an assertion between substantive or registration states with a reason and effective instant.", "inputs": [ "Assertion identifier", "Target status", "Reason code and justification", "Effective instant", "Acting agent identity" ], "outputs": [ "Updated assertion version", "State change event", "Downstream impact list for derived assertions" ], "preconditions": [ "Transition is legal in the declared transition matrix", "Acting agent holds a role permitting the transition", "Reason code is mandatory for suspension, revocation and termination" ], "effects": [ "Prior version is preserved and linked", "Derived and dependent assertions are queued for re-evaluation", "A state change event is emitted" ], "source_refs": [ "SRC-004", "SRC-007", "SRC-008" ] }, { "id": "correct-role-assertion", "name": "Correct a role assertion retroactively", "description": "Record a correction to a previously asserted fact without losing what the register previously believed.", "inputs": [ "Assertion identifier and target version", "Corrected field values", "Change reason distinguishing correction from real-world change", "Supporting evidence reference" ], "outputs": [ "New version linked by a correction-of reference", "Corrected as-of views", "Notification to prior recipients where required" ], "preconditions": [ "Caller is authorized to correct records owned by the record owner", "Evidence meets the minimum corroboration level for the role type" ], "effects": [ "The superseded version remains readable for audit", "Knowledge-time queries before the correction still return the prior belief", "Recipients recorded in the disclosure log are notified where obliged" ], "source_refs": [ "SRC-006", "SRC-008", "SRC-009" ] }, { "id": "record-delegation", "name": "Record a delegation", "description": "Record that a holder exercises a role on behalf of another party, with scope, limits and revocability.", "inputs": [ "Delegating party and delegate party", "Scope of delegated authority and limits", "Validity period", "Sub-delegation permission", "Delegation instrument reference" ], "outputs": [ "Delegation record linked to the affected assertion", "Updated delegation chain depth", "Constraint check result" ], "preconditions": [ "Delegator holds the authority being delegated at the effective instant", "Delegate and delegator are distinct unless a recorded exception applies", "Chain depth remains within the declared maximum and is acyclic" ], "effects": [ "The assertion's on-behalf-of reference is set", "Revocation of the delegation becomes checkable through the instrument's status", "Acts performed under the delegation become attributable to both parties" ], "source_refs": [ "SRC-001", "SRC-006", "SRC-009" ] }, { "id": "verify-role-evidence", "name": "Verify role evidence", "description": "Examine the evidence supporting an assertion and record the corroboration level reached.", "inputs": [ "Assertion identifier", "Evidence references and content hashes", "Verification procedure identifier", "Verifier identity" ], "outputs": [ "Verification report", "Updated corroboration level and verified-at instant", "Exceptions raised for missing or expired evidence" ], "preconditions": [ "Evidence is resolvable and its hash matches the recorded value", "Verifier meets the independence requirement for the role type" ], "effects": [ "Corroboration level and next revalidation instant are updated", "A serial verification report is issued", "Assertions failing verification are flagged rather than silently retained" ], "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "succeed-role-holder", "name": "Succeed a role holder", "description": "End one holding and begin its successor in the same position, recording the handover and any gap or overlap.", "inputs": [ "Outgoing assertion identifier", "Incoming player reference", "Handover instant", "Outstanding matters transferred" ], "outputs": [ "Ended outgoing assertion and new incoming assertion", "Handover record", "Gap or overlap warning where the rules are breached" ], "preconditions": [ "Position permits succession and the incoming player kind is admissible", "Overlap or gap is within the declared tolerance or an exception is approved" ], "effects": [ "Succession references are written in both directions", "Accountability for the interval is explicitly assigned", "A handover record is issued in the serial series" ], "source_refs": [ "SRC-002", "SRC-005", "SRC-008" ] }, { "id": "map-role-to-external-term", "name": "Map a role type to an external term", "description": "Record or update a crosswalk entry between a local role type and an external construct, with relation strength and evidence.", "inputs": [ "Local role type IRI", "Target construct IRI with standard name and version", "Proposed relation strength", "Mapping evidence and reviewer" ], "outputs": [ "Crosswalk entry", "Conflict register entry where standards disagree", "Updated conformance claim status" ], "preconditions": [ "Target standard version is cited with a resolvable URL", "Reviewer is independent of the proposer for exact mappings" ], "effects": [ "A new crosswalk release is issued rather than the prior one being edited", "No conformance claim is recorded without cited evidence", "Conflicts are registered with a dated precedence decision" ], "source_refs": [ "SRC-001", "SRC-013", "SRC-014", "SRC-017" ] }, { "id": "apply-retention-decision", "name": "Apply a retention or erasure decision", "description": "Execute a retention, redaction, tombstoning or hold decision against an assertion and its history.", "inputs": [ "Assertion identifier", "Decision type and authority", "Erasure request reference where applicable", "Legal hold matter reference where applicable" ], "outputs": [ "Updated retention state or tombstone", "Disposition log entry", "Impact report on referencing assertions" ], "preconditions": [ "No active legal hold blocks the decision", "Retain-until instant has passed for disposal actions", "Dual authorization is present for hard deletion" ], "effects": [ "Erased content is irreversibly removed while the tombstone preserves identifier, role type, period and status", "Referencing assertions are updated to point at the tombstone rather than dangling", "The disposition log entry outlives the record it describes" ], "source_refs": [ "SRC-006", "SRC-008", "SRC-009" ] }, { "id": "publish-role-register-snapshot", "name": "Publish a role register snapshot", "description": "Emit an as-of, tier-appropriate projection of the role register for external consumption.", "inputs": [ "As-of effective instant and knowledge instant", "Projection profile and disclosure tier", "Scope filter over hosts or role types" ], "outputs": [ "Snapshot with completeness flag and applied filter", "Canonical form digest", "Manifest citing the vocabulary, constraint and crosswalk versions in force" ], "preconditions": [ "Requested tier is authorized for the intended audience", "All included assertions meet the minimum corroboration level for publication" ], "effects": [ "The snapshot is immutable and separately identified once published", "Disclosure log entries are written for restricted-tier snapshots", "Consumers can reproduce the snapshot from the version history and the manifest" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-010" ] } ], "composition": [ { "target": "Party / Agent identity model (person, organization, group, automated agent)", "relation": "REFERENCE", "purpose": "Supplies the player and scoping-party identity that this mixin references but never restates; identifier schemes such as LEI or ORCID are resolved there.", "required": true, "source_refs": [ "SRC-005", "SRC-008", "SRC-017" ] }, { "target": "Role type vocabulary / concept scheme model", "relation": "REFERENCE", "purpose": "Supplies governed role terms, their axis assignment, status, broader relations and successor mappings; the mixin binds to a named vocabulary version rather than embedding terms.", "required": true, "source_refs": [ "SRC-013", "SRC-014", "SRC-017" ] }, { "target": "Identifier and identity-resolution mixin", "relation": "MIX-IN", "purpose": "Supplies the identity priority ladder, minting rules and alias retention used for assertion identifiers and for resolving player and host references through merges and splits.", "required": true, "source_refs": [ "SRC-008", "SRC-011" ] }, { "target": "Temporal validity (bitemporal period) mixin", "relation": "MIX-IN", "purpose": "Supplies interval semantics, boundary inclusivity, the separation of effective time from knowledge time, and RFC 3339 timestamp rules used by every period on an assertion.", "required": true, "source_refs": [ "SRC-008", "SRC-010" ] }, { "target": "Provenance and assertion-record mixin", "relation": "MIX-IN", "purpose": "Supplies the qualified agent-activity-entity pattern used to record who asserted the role, under what plan, from what source, and when it was recorded versus when it occurred.", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "target": "Activity / event model (host context)", "relation": "REFERENCE", "purpose": "Provides activity and event hosts for activity-scoped roles; the mixin supplies the role qualification while the activity model supplies the occurrence.", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "target": "Object / resource model (host context)", "relation": "REFERENCE", "purpose": "Provides object and resource hosts for object-scoped roles such as custodian, owner and rights holder, which PROV-O cannot express through hadRole alone.", "required": false, "source_refs": [ "SRC-001", "SRC-014", "SRC-017" ] }, { "target": "Agreement / contract model", "relation": "REFERENCE", "purpose": "Supplies the agreements that confer contractual roles and the binding instruments required where a role acts on another party's behalf.", "required": false, "source_refs": [ "SRC-007", "SRC-009" ] }, { "target": "Organization and organizational structure model", "relation": "ALIGN", "purpose": "Overlaps where the host is an organization; org:Membership and org:Post must be mapped to the assertion and position constructs rather than duplicated, with the precedence decision recorded.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "Access control / authorization policy model", "relation": "ALIGN", "purpose": "Consumes party roles as inputs to policy decisions; the boundary is that this mixin carries no permissions and an RBAC role is a different construct that happens to share the word.", "required": false, "source_refs": [ "SRC-003", "SRC-015" ] }, { "target": "Evidence and attestation model (verifiable credentials, filed documents)", "relation": "REFERENCE", "purpose": "Supplies the documents and credentials that substantiate a role assertion, together with their validity windows and revocation status.", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "target": "Consent and lawful-basis model", "relation": "REFERENCE", "purpose": "Holds the lawful basis relied upon for processing and disclosing role assertions about natural persons; the mixin references it rather than determining it.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Retention and disposition schedule model", "relation": "REFERENCE", "purpose": "Supplies retention classes, disposal triggers and legal hold mechanics applied to ended role assertions and their history.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Jurisdiction and legal mandate model", "relation": "REFERENCE", "purpose": "Supplies the statutes, orders and jurisdictional scopes cited as the basis of authority and as the source of obligations attaching to statutory role types.", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "target": "Party-to-party relationship register model (ownership, consolidation)", "relation": "ALIGN", "purpose": "Adjacent construct for structural relationships between legal entities; the adopting Dimension must decide per relationship type whether it is a role assertion or a relationship record and record that decision to avoid double representation.", "required": false, "source_refs": [ "SRC-008" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Designate a single accountable owner for the Party Role package who is itself recorded as a Party Role assertion on the package, so the governance model is self-describing.", "Declare, before first use, which host models the mixin may be applied to and register each application with its host kind, permitted role types and cardinality constraints.", "Nominate the authoritative master system for player identity and for each host kind, and publish the identifier priority actually applied so the third-tier UUID fallback is auditable.", "Publish and version the role type vocabulary, cardinality constraint set, segregation ruleset, scope profile, derivation ruleset and canonical projection profile as citable artifacts before any assertion is published.", "Record a dated precedence decision wherever an aligned external standard conflicts with the local model, rather than silently choosing one." ], "namespace_guidance": "Mint a stable Dimension namespace base for locally issued assertion, position, vocabulary, ruleset and profile IRIs; keep it distinct from any host or party namespace. Never reuse a retired IRI for a new meaning, never encode mutable facts such as player name, role label or dates in an IRI path, and prefer the external governed identifier (LEI, ORCID, DID, standard term IRI) over a local IRI whenever one exists. Local terms live in a clearly separated local subspace so consumers can tell governed from local at a glance.", "registry_links": [ "Registry entry vr.wm-xct-023 (WM-XCT-023 Party Role), nav path NAV.XCT.ROLE, domain tag XCT.ROLE, review state boundary-review-required", "Role type vocabulary registry holding each released vocabulary version and its term IRIs", "External alignment registry holding the crosswalk releases, conflict register and conformance claim status per target standard", "Position and constraint registry holding role position definitions, cardinality constraint sets and segregation rulesets with their effective-from instants" ] }, "canon_and_patch": { "canonicalization_rules": [ "Serialize the invariant field set only, with deterministic key ordering and Unicode NFC normalization of all text values, before hashing.", "Represent every timestamp as an RFC 3339 date-time with seconds and an explicit offset or Z; additionally carry a derived UTC instant for ordering, and never normalize away the original offset because it may be legally relevant.", "Express references as identifier plus scheme; dereferenceable links are projection-local and are excluded from the canonical form.", "Distinguish absent from null explicitly: an absent valid-until means open-ended only when the explicit open-ended marker is present, otherwise it is a validation error.", "Exclude derived and computed fields, including cascade-derived holdings and quality measures, from the canonical form so recomputation does not appear as a change." ], "patch_rules": [ "Status transitions are append-only events; the assertion's current status is a projection of the event series, never edited in place.", "A correction creates a new version carrying a correction-of reference and a change reason distinguishing correction from real-world change; the superseded version stays readable.", "Never silently mutate valid-from, player reference, host reference or role type; a change to any identity-bearing attribute creates a new assertion linked by succession or supersession.", "Erasure replaces content with a tombstone that preserves identifier, role type, period and status; it never removes the record node, because referencing assertions would dangle.", "Every patch records the acting agent, the rule-artifact versions in force and both the effective and recorded instants." ], "compatibility_rules": [ "Adding an optional field or a new artifact type is a minor change; narrowing cardinality, adding a required field, or removing or retyping a role term is breaking.", "Deprecating a vocabulary term requires a successor mapping and a published transition period before the term is retired; retired term IRIs are never reused.", "Consumers must declare a minimum supported vocabulary and profile version; producers must not emit terms newer than a negotiated version without the consumer's declared fallback behaviour.", "Projection profiles are versioned independently of the model; a projection change that alters which invariant fields are carried is breaking even if the model is unchanged." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record for the artifact's subject, where such a system exists and is named in the Dimension package.", "Governed global identifier or IRI from an external authority, such as an LEI, ORCID, DID or a standard vocabulary term IRI, where no master-system identifier applies.", "UUIDv7 per RFC 9562, or a ULID, minted in the adopting Dimension's namespace, used only as the last resort and recorded as such.", "A date, a name, a role label, a file path or a sequence position is never an identifier; serial numbering is a naming convention layered on top of a real identifier, not a substitute for one." ], "timestamp_rule": "All artifact timestamps use RFC 3339 date-time with seconds and an explicit numeric offset or Z. Event time and observation or ingestion time are recorded as separate fields and never conflated; '-00:00' is used only to signal that UTC is known but the local offset is not. Where legal effect depends on local time, the jurisdictional time zone identifier is recorded alongside the offset.", "serial_naming_rule": "Serial artifacts (version history entries, status transition events, verification reports, handover records, disclosure and disposition log entries, identifier allocation entries, vocabulary and crosswalk releases) carry a monotonic sequence within a named series plus their own identifier per the identity priority and an RFC 3339 issuance instant. Sequence numbers are never reused after a gap and never carry meaning beyond ordering within their series; a gap must be explainable from the log itself.", "integrity_rule": "Every published artifact carries a digest over its canonical form and cites the versions of the vocabulary, constraint set, ruleset and projection profile in force when it was produced. Evidence references bind to a content hash so a reference cannot silently come to point at different text. Snapshots and reports are immutable once published: corrections are issued as new serial entries that reference the superseded one, never by editing in place." }, "policies": [ "No conformance to an external standard is claimed without cited evidence; alignments are recorded with an explicit relation strength and every known conflict is registered with a dated precedence decision.", "A role assertion never carries permissions, credentials or party master data; any attempt to store them in characteristics is a validation failure, because it would create a shadow authorization system outside the access model.", "Historical role assertions are retained by default and disposed of only under a named retention class or a lawful erasure decision; erasure produces a tombstone so accountability chains cannot be broken by deletion.", "Every assertion records who asserted it and on what basis; unattributed assertions are not publishable at any disclosure tier above internal.", "Where a role type is determined by statute or by factual conduct, the register is treated as declaratory rather than constitutive unless the governing instrument says otherwise, and reclassification triggers are documented per role type.", "Structural nodes lacking primary source support are marked as gaps in the coverage record rather than presented as canonical.", "Occupancy does not imply permission; implicit access grants are forbidden unless a sibling permission object is explicitly derived.", "Qualifications and licences do not imply occupancy; occupancy may auto-suspend when a required credential expires if that policy is set.", "Physical deletion of role history is refused in favour of revocation plus retention; lawful erasure redacts player fields while preserving that a post existed.", "External alignments never constitute a conformance claim without recorded evidence." ], "crud": { "read": [ "Reads are scoped by disclosure tier; restricted-tier reads write a disclosure log entry naming recipient, purpose and field set.", "As-of reads accept both an effective instant and a knowledge instant, and results carry a completeness flag with the filter applied.", "Derived holdings are always distinguishable from directly asserted ones in any read result.", "Tombstoned assertions remain readable at tombstone level so references resolve." ], "create": [ "Creation requires host resolution, an active role term at a pinned vocabulary version, an admissible player kind or a permitted vacancy, and a stated authority basis.", "Cardinality, uniqueness and segregation constraints are evaluated before persistence, not after.", "The identity priority is applied and the tier actually used is recorded on the assertion.", "recorded-at is taken from the register clock and is never supplied by the caller." ], "update": [ "Identity-bearing attributes are immutable; changing one creates a new assertion linked by succession or supersession.", "Corrections create a new version with a correction-of reference and a change reason separating correction from real-world change.", "Status changes go through the transition function and emit an event; direct writes to the status field are rejected.", "Every update records the acting agent and the rule-artifact versions in force." ], "delete": [ "Default disposition is retirement, not deletion; retired assertions remain queryable as historical fact.", "Erasure redacts content and leaves a tombstone preserving identifier, role type, period and status.", "Hard deletion requires dual authorization, a named lawful ground and no active legal hold, and the deletion record itself survives in the disposition log.", "Deleting a vocabulary term, position or ruleset version is prohibited; they are retired with a successor mapping so historical assertions stay interpretable." ] }, "roles": [ { "name": "Party Role steward", "responsibilities": [ "Own the Party Role package for the adopting Dimension and maintain its registered host applications", "Approve creation, correction and retirement of assertions outside the automated path", "Maintain the identity priority decisions and the register of authoritative master systems", "Answer boundary questions between this mixin and its sibling models" ] }, { "name": "Role vocabulary authority", "responsibilities": [ "Own the role type vocabulary, admit and reject terms, and publish versioned releases", "Assign each term a classification axis and maintain broader and successor relations", "Manage deprecation with transition periods and successor mappings", "Prevent reuse of retired term IRIs for new meanings" ] }, { "name": "Assertion verifier", "responsibilities": [ "Execute the verification procedure and record the corroboration level reached", "Validate evidence references against their content hashes and expiry", "Issue serial verification reports and raise exceptions for stale or missing evidence", "Maintain independence from the asserting party for exact and high-tier verifications" ] }, { "name": "Constraint and segregation officer", "responsibilities": [ "Maintain the cardinality constraint set and the segregation of duties ruleset", "Adjudicate conflict of interest declarations and approve time-limited exceptions with compensating controls", "Run backfill scans when a new rule is introduced and set remediation deadlines", "Reconcile conferred representation authority against permissions granted in the access model" ] }, { "name": "Privacy and retention officer", "responsibilities": [ "Assign disclosure tiers and approve movements of fields to wider tiers", "Maintain retention classes, legal holds and the disposition log", "Handle erasure requests, tombstone creation and recipient notification", "Assess re-identification risk for role-only and pseudonymous disclosures" ] }, { "name": "Interoperability custodian", "responsibilities": [ "Maintain the alignment crosswalk, conflict register and conformance claim statuses", "Verify that no direct external property is reused outside the scope its standard permits", "Own the canonical projection profile and validate that each projection preserves invariants", "Manage version negotiation expectations with external consumers" ] } ], "access": { "default_rule": "Deny by default. Read access to a role assertion is granted only for a named purpose at a specific disclosure tier, and is evaluated against the caller's own recorded roles rather than against ambient system permissions; the assertion itself never grants access to anything.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Statutory publication duties may require public disclosure of specified fields for specified role types regardless of the holder's preference; the duty must be cited on the assertion.", "The named record owner and the Party Role steward may read across disclosure tiers for maintenance, with every such read logged and periodically reviewed.", "Break-glass read for incident response or safeguarding is permitted with dual authorization, a stated ground and mandatory post-hoc review within a declared window.", "A role holder may always read the assertions naming them, subject to redaction of third-party identities and of adjudication material where disclosure would prejudice an open dispute.", "Legal hold overrides erasure and retention-driven suppression until the hold is released.", "Public point-of-contact or provider-directory publication of named fields.", "Break-glass emergency read of active occupancy for a scoped activity, fully audited.", "Lawful erasure redaction of player fields while preserving assignment identifiers and lifecycle events." ], "audit_requirements": [ "Every restricted-tier read, every disclosure to an external recipient and every break-glass access is logged with caller, purpose, field set, RFC 3339 instant and the authorization decision.", "Every write records the acting agent, the acting agent's own role, the change reason and the versions of vocabulary, constraint set and ruleset in force.", "Audit records are append-only, retained beyond the assertions they describe, and covered by the disposition log rather than by ordinary record deletion.", "Access and disclosure logs are reviewable independently of the Party Role steward, so the steward's own access is subject to review by someone else.", "All create, status change, handover, delegation and break-glass reads emit a lifecycle or provenance event with event_time, recorded_time and agent.", "who/player and on_behalf_of inequality is validated and failures are logged." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Owner", "Vocabulary Release URL", "Constraint and Ruleset URL" ], "read_order": [ "AGENTS.md at the package root, to obtain Name, Type, Model ID, Owner and the four required URLs before any other action", "Specification URL, for the scope statement, boundary notes and the bundle/layer/finding structure that defines what a Party Role assertion means", "Storage type URL, for the concrete projection in use (document store, graph, tabular, repository) and its canonicalization and identifier rules", "Interface URL, for the read, create, update, delete and event contracts and the disclosure tiers each exposes", "Processes URL, for the assert, validate, verify, transition, correct, succeed and dispose procedures and their preconditions", "Vocabulary Release URL and Constraint and Ruleset URL, pinned to the versions cited by the artifact being read, before validating or emitting any assertion" ] } }, "coverage": { "claim": "Claude's decomposition is adopted as the spine (reified role assertion, classification and vocabulary governance, host and player binding, bitemporal validity, authority basis, delegation, multiplicity and segregation, provenance and evidence, disclosure and retention, alignment and projection invariants), extended by five grok findings covering role-local contact context, ultimate-versus-immediate agency, credential-conditioned occupancy, the standing-versus-participation discriminator and the RoleClass exclusion gate. This is a defensible operating surface for a party-role mixin across the profiles actually evidenced here — healthcare, geospatial metadata, telecom, LEI relationship records, trade role codes, research credit — and is explicitly not a universal or complete role ontology; financial-messaging (ISO 20022), FIBO and supply-chain (EPCIS) treatments remain ungrounded.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Assertion identity, sameness rules and the three-tier identity priority are grounded in RFC 9562, GLEIF's use of LEI or ISO 17442-compatible identifiers, TMF669's id/href and FHIR's identifier 0..*. The rule that a date or role label is never an identifier is a model rule, not a cited requirement." }, { "dimension": "lifecycle", "status": "covered", "notes": "Two separate state machines (substantive role status and registration status) follow GLEIF's RelationshipStatus versus nine-value RegistrationStatus; transitions and reason codes follow TMF669 status/statusReason and its StateChange event; suspension and revocation follow W3C VC credentialStatus." }, { "dimension": "relationships", "status": "covered", "notes": "Host binding, scoping party, delegation chains, succession and derived holdings are covered. The player/scoper distinction rests principally on HL7 RoleClass, which was the weakest-verified retrieval in this set." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 governs every timestamp with mandatory seconds and explicit offset. Role period is supported by org:memberDuring, FHIR period, TMF validFor, schema.org startDate/endDate and VC validFrom/validUntil; the bitemporal split is supported by FHIR occurred versus recorded and by GLEIF's three period types plus registration dates." }, { "dimension": "provenance", "status": "covered", "notes": "Asserting agent, agent's own role, source system, plan and party tier follow PROV-O's qualified Association, Attribution and Delegation pattern and FHIR Provenance agent.who/onBehalfOf/recorded. Provenance of the assertion is kept explicitly distinct from provenance of the host." }, { "dimension": "ownership", "status": "covered", "notes": "Record ownership and the accountable maintainer are asked directly; conferring authority and mandate are separate from record ownership. GLEIF's ManagingLOU is the operational precedent for a named record maintainer distinct from the subject." }, { "dimension": "validation", "status": "covered", "notes": "Well-formedness, vocabulary binding strength, cardinality, temporal and segregation checks are all specified with named rule artifacts. Binding strength values follow FHIR's required/extensible/preferred/example scheme; segregation follows NIST RBAC static and dynamic separation of duty." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with named-purpose tiered reads, five exception classes and four audit requirements. The explicit non-grant rule (a party role confers no permissions) is the load-bearing boundary against NIST RBAC." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention classes, retain-until, tombstones preserving referential integrity, legal hold and dual-authorized hard deletion. Grounded in GDPR storage limitation and erasure, and in GLEIF's practice of retiring rather than deleting relationship records." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignment relations with evidence, a conflict register with dated precedence decisions, explicit conformance claim status, and projection invariants with a canonical form. Ten external constructs are mapped." }, { "dimension": "classification", "status": "covered", "notes": "Four classification axes with vocabulary binding and governance, grounded in FHIR Provenance's functional/structural split and in three independent governed vocabularies (CRediT, DataCite contributorType, ISO 19115-1 CI_RoleCode)." }, { "dimension": "authority and delegation", "status": "covered", "notes": "Authority basis, conferring instrument, constitutive versus declaratory registration, statutory obligations and delegation chains. GDPR Articles 4, 26 and 28 supply the statutory case; PROV-O and FHIR supply the delegation pattern." }, { "dimension": "constraints and separation of duties", "status": "covered", "notes": "Cardinality, uniqueness, mandatory roles, share summation, incompatible pairs, static versus dynamic separation, time-limited exceptions and backfill on rule change." }, { "dimension": "scope and extent", "status": "covered", "notes": "Spatial, jurisdictional, organizational-unit, quantitative and characteristic-based narrowing, grounded in ISO 19115-1 CI_Responsibility extent, FHIR location/specialty/service, GLEIF qualifiers and quantifiers and TMF669 typed characteristics." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Evidence references with content hashes, graded corroboration modelled on GLEIF's four validation source levels, verification process and independence, staleness triggers, dispute and annulment." }, { "dimension": "privacy", "status": "covered", "notes": "Disclosure tiers, minimized projections, role-only and pseudonymous disclosure, lawful basis referenced rather than determined here, and recipient logging grounded in GDPR Article 4(9) and 4(10)." }, { "dimension": "measurement", "status": "covered", "notes": "Quantitative extent with units and currency, share summation constraints and quality measures. Support is thinner than for other dimensions: GLEIF quantifiers are the main precedent and the summation constraint is a model rule." }, { "dimension": "spatial", "status": "covered", "notes": "Spatial extent of the role is directly supported by ISO 19115-1 CI_Responsibility.extent ('spatial or temporal extent of the role') and by FHIR PractitionerRole.location. Geometry representation itself is delegated to a geospatial sibling model." }, { "dimension": "security", "status": "covered", "notes": "Treated strictly as a boundary: representation authority is distinguished from system permissions, and reconciliation between the two is assigned to a named role. The mixin deliberately carries no security semantics." }, { "dimension": "event", "status": "covered", "notes": "State change, create, attribute change and delete events follow TMF669's four notification types; the event carries both event time and ingestion time per RFC 3339." } ], "known_omissions": [ "No primary source was obtained for ISO 20022's BusinessRole definition; two fetch attempts timed out, so the ISO 20022 view of role-versus-actor is absent from the grounding and is a genuine evidence gap for financial-messaging adopters.", "ISO 19115-1 itself is paywalled and was not read directly; CI_Responsibility and CI_RoleCode are grounded in ICSM's public documentation of it, so exact normative wording is not verified.", "The HL7 v3 RoleClass page rendered navigation only on direct fetch; the player/scoper definitions were confirmed via the search index against the same URL. The scoping-party construct therefore has the weakest verification in the model.", "FIBO's PartyInRole was identified as directly relevant but its ontology page could not be rendered, so the financial-industry treatment of party-in-role is not cited as support anywhere.", "GS1 EPCIS 2.0 (owning_party versus possessing_party on supply-chain events) would have been a strong independent case of object-scoped roles distinguishing legal from physical control; the specification PDF could not be parsed and the distinction is not represented in the model.", "Role naming and honorifics, multilingual role labels, and transliteration are not modelled; they are delegated to the vocabulary model without a specified contract.", "Machine-readable representation limits are required but no constraint expression language is prescribed, because no cited source supplies one for this purpose.", "No cited source establishes a maximum delegation chain depth; the depth limit is a model-imposed safeguard and should be treated as a local policy parameter, not a standard.", "Group and collective players are permitted but the internal accountability decomposition within a collective is not modelled and is left to the party model.", "The role-only disclosure and re-identification risk guidance is stated as a requirement without a cited methodology for assessing that risk.", "EDM Council FIBO PartyInRole / agent-in-role was discovered but the ontology viewer page did not yield a citable class definition in this run; treat FIBO as an ungrounded alignment candidate.", "NIST RBAC / INCITS 359 and ABAC (SP 800-162) were not fetched; permission objects remain a sibling and a dedicated RBAC alignment is a gap.", "GDPR controller/processor and eIDAS representative powers were not taken from legislative text; legal-capacity roles are a regional gap.", "Verifiable Credentials for role occupancy are emerging and lack a primary source in this bundle.", "A universal role-conflict matrix does not exist in the cited sources; incompatibilities are Dimension-local.", "RACI, Open Contracting party roles and GLEIF relationship records were not grounded.", "Robotics-specific operator roles were out of demand (factor_robotics 0.00) and are omitted.", "UN/CEFACT list is much larger than the findings enumerate; adopting Dimensions must snapshot the list rather than rely on this mixin to enumerate every code." ], "conflicts": [ "PROV-O restricts prov:hadRole to prov:Association, so roles in PROV attach to agent-activity involvement, not to entities. Object-scoped roles (custodian, owner, rights holder) cannot be expressed with prov:hadRole without misuse; they require prov:qualifiedAttribution with a locally defined role property. This directly contradicts the registry purpose 'role scoped to an object or activity' and is the single largest alignment conflict.", "W3C org:Membership is defined only over an Organization, whereas ISO 19115-1 CI_Responsibility binds a party's role to a described resource. Adopters whose hosts include both will find the two patterns overlap without a common supertype; a precedence decision is required.", "NIST/INCITS RBAC and this model both use the word 'role' for incompatible constructs: a permission bundle evaluated at access time versus a business or legal assertion about standing. Naming collisions in code and vocabulary are near-certain and must be managed deliberately.", "FHIR separates agent.type (functional, bound to Participation Role Type) from agent.role (structural, bound to Security Role Type), while PROV-O, schema.org and TMF669 each use a single undifferentiated role slot. Round-tripping between them loses the axis distinction unless it is carried explicitly.", "GDPR determines controller and processor status from factual conduct, so a register entry can be legally wrong while being procedurally correct. Systems that treat the register as constitutive will misclassify; the constitutive-versus-declaratory flag exists precisely because no single answer is correct across role types.", "schema.org Role and TMF669 PartyRole both permit free-text role names, whereas CRediT, DataCite and ISO 19115-1 supply closed vocabularies. Ingesting from the former into the latter is lossy and requires an explicit escape term.", "GLEIF's relationship records model parent-subsidiary as a relationship rather than a role, while the same fact is plausibly a role assertion. Representing it both ways in one Dimension produces double counting; this boundary remains unresolved and is flagged in the registry as boundary-review-required.", "ISO 19115 profiles that require exactly one CI_RoleCode per CI_Responsibility conflict with FHIR PractitionerRole.code 0..*.", "HL7 EMP (employment) versus ASSIGNED (functional role) versus Schema.org OrganizationRole (membership qualifier) are not equivalent.", "ISO 20022 PartyRole on a payment instance leans toward participation-in-transaction; FHIR PractitionerRole is a standing assignment; merging them loses meaning.", "PROV Role may apply to non-agent entities; this mixin refuses that case.", "FHIR Provenance.agent.type (functional participation) versus agent.role (security role example) versus PractitionerRole.code (standing function) are three different classifiers.", "English labels such as owner, agent, processor and author are not portable across CI_RoleCode, UN/CEFACT and ISO 20022 without a conflict-annotated map.", "IBM documentation of ISO 20022 Role is secondary; it may lag the Registration Authority dictionary." ], "regional_assumptions": [ "GDPR is used as the worked example of statutory roles because it is publicly citable and precise. Adopters outside the EU and EEA must substitute their own equivalents; the controller/processor pattern is not universal and the obligation attachment mechanism, not the specific roles, is what generalises.", "Publication duties for roles such as company directors, beneficial owners and licensed professionals vary sharply by jurisdiction. The disclosure tier model is deliberately parameterised rather than prescribing a default public tier.", "The identifier priority assumes governed global identifiers such as LEI and ORCID are available. In jurisdictions or sectors where they are not, the UUIDv7 fallback will be used far more often than the ladder implies, weakening cross-system resolution.", "Legal effect of a role frequently depends on local civil time (for example an appointment effective at midnight local). The model records an offset per RFC 3339 and additionally a jurisdictional time zone identifier, but does not resolve which prevails where they disagree.", "Names, honorifics and legal capacity rules for who may hold a role differ by jurisdiction and are delegated entirely to the party model; no assumption of a Western name or capacity model is embedded here.", "Retention periods are stated as classes rather than durations because statutory minimums for role history differ by sector and country.", "Healthcare licensing and PractitionerRole usage are jurisdiction-specific; FHIR example bindings are not a world code list.", "ISO 19115-1 responsible-party practice is described via ICSM (Australia) guidance; other profiles may constrain CI_RoleCode differently.", "UN/CEFACT trade roles assume cross-border commercial process semantics that may not fit domestic public-sector posts.", "Retention, erasure and public-directory publication depend on local public-records, employment and data-protection law.", "Company-officer and signing-authority roles (SGNOFF) vary by corporate law and were not taken from a specific companies statute." ], "adversarial_checks": [ "Attempted to justify a single generic 'role' property attaching a party directly to a host and rejected it: three independent vocabularies (PROV-O, W3C org, schema.org) reify the link precisely because qualifying facts such as period, extent and delegation cannot attach to a binary property. The binary form is retained only as a declared-lossy projection.", "Tested whether 'party role' and 'RBAC role' could be unified into one model. Rejected: INCITS 359 roles carry permissions and are evaluated at access time, while party roles are assertions about standing that may exist with no system access at all. Unifying them would create a shadow authorization system inside a business model, so the boundary is enforced by an explicit policy that assertions carry no permissions.", "Searched for a counterexample to the claim that roles are always time-bounded. Found one class that resists it: originator and author in ISO 19115-1 and DataCite, which are historical facts that never end. The model handles these with an explicit open-ended marker rather than a sentinel end date, and forbids null-as-unbounded ambiguity.", "Tested whether a role always has a player. Found two counterexamples in primary sources: org:Post exists independently of any holder, and FHIR permits a PractitionerRole with an empty practitioner. Player reference was therefore made optional at 0..1 with an explicit vacancy status, rather than mandatory as first drafted.", "Tested whether the host is always distinct from the scoping party. HL7 RoleClass shows they are not: a role can be scoped by one entity and exercised over another. The scoping party was added as a separate optional slot rather than collapsed into the host.", "Attempted to claim conformance to PROV-O and withdrew it: prov:hadRole's restriction to Association makes object-scoped roles non-conformant if expressed with that property. Recorded as the primary conflict and reflected in the alignment finding's second question rather than papered over.", "Tested whether deletion could simply remove a role assertion. Rejected: ended roles are load-bearing for accountability and are referenced by provenance and succession chains, so unconditional deletion breaks referential integrity. Tombstoning was made mandatory and hard deletion gated behind dual authorization.", "Checked whether the model duplicates a composable sibling. Found real overlap with org:Membership for organization hosts and with GLEIF-style relationship records for party-to-party structure; both were downgraded from CHILD or COMPOSE to ALIGN with a required precedence decision rather than absorbed.", "A date must never be accepted as assignment identity even if it uniquely locates a posting in a local spreadsheet.", "An empty player is valid vacancy, not a data-quality error, when unnamed occupancy is authorised.", "Holding EMP or a qualification must not auto-create this mixin occupancy.", "A PROV Role on a non-agent entity (the mixing-implement case) must be rejected as out of scope.", "Occupancy must not be treated as an access grant without a sibling permission object.", "who/player equal to onBehalfOf must fail validation.", "Claiming conformance to UN/CEFACT or ISO 19115 solely because a display name matches is forbidden without a versioned map and evidence.", "Physical delete of an active assignment must be refused in favour of revoke-or-end-role." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both providers independently reached entry_kind=mixin with matching negative scope: the model references but never owns party master data, never carries host payload, and never mints permissions. Claude additionally fixes the spine as a reified n-ary assertion (player, host, role type, validity) and grok's assignment record is the same construct under another name, so no reclassification, split or merge is warranted. The boundary is settled before any node is accepted; the only unsettled edges (ownership-as-property-right versus the sibling Ownership and Stewardship entry, and GLEIF parent/subsidiary as relationship versus role) are parameterised registry precedence decisions, not entry-kind questions." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude as base", "rationale": "Claude carries eight sourced boundary notes, an explicit nine-item out-of-scope list, a conflict register and adversarial checks, and covers disclosure, retention, vocabulary governance and projection invariants that grok leaves entirely to Dimension policy. Size was not decisive; boundary completeness and source authority were." }, { "concept": "Entry kind", "disposition": "accepted as mixin", "rationale": "Independent agreement across providers, with matching negative scope on party master data, host payload and permissions. No evidence in either pack supports promoting this to a standalone entity or splitting it." }, { "concept": "Reified assertion as model spine", "disposition": "accepted from base", "rationale": "Claude's reified n-ary node and grok's assignment record are the same construct; base wording is retained because it names the qualifying facts (period, extent, evidence, delegation) that cannot attach to a binary property, and marks the binary form as a declared-lossy projection." }, { "concept": "Role-local contact and service context", "disposition": "accepted from grok into scope-qualifiers", "rationale": "Genuine gap: contact, availability and endpoint attached to the post rather than the person, with an explicit override rule against party-master contact. Grounded in FHIR PractitionerRole and ISO 19115-1 CI_Party." }, { "concept": "Ultimate versus immediate party in agency chains", "disposition": "accepted from grok into delegation-and-representation", "rationale": "The base delegation chain has depth and revocation but no principal/immediate-agent distinction and no direct-versus-indirect representation split; UN/CEFACT and PROV supply both, and they change who is bound by an act." }, { "concept": "Credential-conditioned occupancy", "disposition": "accepted from grok into authority-basis", "rationale": "The base covers only the negative rule that a qualification does not imply a role. Occupancy preconditions, issuing scoper and auto-suspension on credential lapse are missing and are operationally decisive for licensed posts." }, { "concept": "Standing assignment versus act participation discriminator", "disposition": "accepted from grok into external-alignment", "rationale": "The base declares this boundary in prose but supplies no question that forces a record to declare its mode, and no constraint forbidding the merge of standing occupancy with act participation." }, { "concept": "RoleClass exclusion gate", "disposition": "accepted from grok into classification-and-vocabulary", "rationale": "The base never excludes partitive, ontological or passive-material roles, nor PROV Role on non-agent entities. For a mixin this is boundary-critical and is directly grounded in HL7 RoleClass at tier 1." }, { "concept": "grok permission-boundary finding", "disposition": "rejected as duplicative", "rationale": "The base already enforces the non-grant rule through its NIST RBAC boundary note and the representation-versus-permission question; a second finding would create a competing statement of the same rule that could drift." }, { "concept": "grok external-code-alignment-and-conflicts", "disposition": "rejected as duplicative and narrower", "rationale": "The base alignment finding already requires directional mappings with relation strength, a dated conflict-precedence register and evidence for any conformance claim, across ten external constructs rather than five." }, { "concept": "grok functional-role-code and named-position labels", "disposition": "rejected; label question deferred", "rationale": "Coded role typing is fully covered by the base classification and vocabulary-governance findings. Multilingual labels and label-versus-code precedence are a declared base omission delegated to the vocabulary model and rest on a tier-2 source only, so they are deferred rather than bolted on." }, { "concept": "grok access-privacy-and-exceptions", "disposition": "rejected as narrower", "rationale": "The base disclosure finding covers tiers, minimization, role-only disclosure, lawful-basis referencing and recipient logging; break-glass and public-directory publication are instances of its exception classes, not new structure." }, { "concept": "grok detect-role-conflict function", "disposition": "rejected as duplicative", "rationale": "The base validate-role-assertion already names cardinality, segregation and representation checks, which cannot be evaluated without inspecting the player's wider assignment set; a separate function would split one rule engine in two." }, { "concept": "ISO 20022 PartyRole evidence", "disposition": "rejected as grounding; deferred to research", "rationale": "Grok's only ISO 20022 source is IBM product documentation, non-primary at tier 3, which grok itself flags as possibly lagging the Registration Authority dictionary. It may not underwrite published structure." }, { "concept": "Ownership as a property right", "disposition": "held for sibling boundary review", "rationale": "Grok excludes it explicitly while the base leaves it fuzzy in the GLEIF boundary note, and a sibling Ownership and Stewardship entry already exists in the registry. A recorded precedence decision is required before publication to prevent double representation." }, { "concept": "PROV-O conformance", "disposition": "alignment only, no conformance claim", "rationale": "prov:hadRole is restricted to prov:Association, so object-scoped roles cannot be expressed with it without misuse. Both providers converge on partial alignment with a locally defined role property, so this is resolved and is not a critical conflict." }, { "concept": "grok bundle player-scope-and-occupancy", "disposition": "not added as structure", "rationale": "Its content maps onto the base scoping-and-composition bundle (host binding, player binding, scope qualifiers) plus the multiplicity layer; only the role-local contact gap was genuinely missing and it was added as a finding, not a bundle." } ], "publicationHolds": [ "Source verification: re-fetch and version-pin every base source plus the grok sources underwriting adopted findings (UN/CEFACT PartyRoleCodeList and partyRoleCode, HL7 RoleClass, FHIR PractitionerRole and Provenance), and reconcile the R5-pinned versus unpinned FHIR URLs the two providers used for the same resources.", "Multi-profile validation: the mixin must be exercised against at least healthcare (PractitionerRole), geospatial metadata (CI_Responsibility), trade/customs (UN/CEFACT), telecom (TMF669), LEI relationship records and research credit (CRediT/DataCite) before any claim that it is domain-neutral; only healthcare and geospatial are jointly evidenced today.", "HL7 v3 RoleClass player/scoper definitions are the weakest verified retrieval in the base (page rendered navigation only; definitions confirmed via search index). Grok fetched the same code system successfully, so re-verify directly before publishing any scoper-dependent structure.", "ISO 19115-1 normative wording is unverified: both providers relied on ICSM's public documentation of a paywalled standard. Mark CI_Responsibility and CI_RoleCode claims as secondary-sourced or obtain the standard.", "Audit the base's ODRL 2.2 citations on player-kind-and-vacancy, role-extent-and-characteristics, statutory-role-obligations, representation-and-limits and disclosure-tiers-and-minimization; ODRL is a rights-expression vocabulary and may be over-cited relative to what it actually states.", "Record registry-level precedence decisions before publication for the two fuzzy sibling boundaries: ownership-as-property-right against the existing Ownership and Stewardship entry, and GLEIF parent/subsidiary represented as a relationship record versus a role assertion." ], "deferredResearch": [ "ISO 20022 BusinessRole and PartyRole from the Registration Authority business model or message dictionary, not vendor documentation: claude's two fetches timed out and grok fell back to tier-3 IBM docs, leaving financial-messaging adopters ungrounded.", "EDM Council FIBO PartyInRole / agent-in-role: both providers identified it as directly relevant and neither could render a citable class definition, so the financial-industry treatment of party-in-role is absent from both packs.", "GS1 EPCIS 2.0 owning_party versus possessing_party on supply-chain events, which would supply an independent case of object-scoped roles separating legal from physical control; the specification PDF could not be parsed.", "Multilingual role labels, honorifics, transliteration and the label-versus-coded-function precedence rule, which need an explicit contract with the vocabulary sibling model rather than a finding here.", "A constraint expression language for machine-checkable representation and signing limits: the base requires machine-checkability but no cited source supplies a suitable expression language for this purpose.", "Whether any authority publishes a reusable role-incompatibility or segregation-of-duties matrix; grok found none in primary sources, so incompatibilities are currently Dimension-local by default rather than by evidence.", "Basis for any maximum delegation chain depth: the base depth limit is a model-imposed safeguard with no standard behind it and should stay a local policy parameter until evidence exists.", "NIST SP 800-162 (ABAC) alongside INCITS 359, to test whether the no-permissions boundary holds equally against attribute-based authorization, which neither provider examined." ] }, "statistics": { "sources": 24, "bundles": 7, "layers": 16, "findings": 31, "questions": 119, "artifacts": 24, "functions": 12 } }