# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-22T15:54:31Z", "synthesisSha256": "4aaf0e3f2c4f3cd66bf393b9e3508da4b52fa503bd689b982aa7ae10b75d2256", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-XCT-011", "registryId": "vr.wm-xct-011", "name": "Identifier Scheme", "version": "0.3.0-research.1", "previousVersions": [ { "version": "0.2.0-legacy", "url": "https://ver.cy/models/world-n8-identifier-and-naming-system/" } ], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "identifier systems", "namespaces", "reference data" ], "tags": [ "identifier", "namespace", "registry", "resolution", "interoperability" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-xct-011-identifier-scheme/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-011", "model": { "registry_id": "vr.wm-xct-011", "model_id": "WM-XCT-011", "name": "Identifier Scheme", "entry_kind": "mixin", "purpose": "Describe a governed naming system as a thing in the world - its constitution, syntax, authority, allocation, lifecycle, resolution, cross-scheme mapping and assurance - so that every other model can carry identifiers by mixing in one scheme-aware structure instead of re-inventing naming rules locally.", "scope_statement": "In scope is the scheme as referent: how a scheme is constituted and registered, what strings it admits, how those strings are compared, who is mandated to allocate them and under what policy, how an identifier is bound to a referent and moves through states, whether and how it resolves, what persistence is promised, how it maps to other schemes, and what quality, privacy and legal constraints attach. Out of scope is the referent itself, the proof that a claimant is the entity a label denotes, and every storage or interface projection.", "in_scope": [ "Scheme constitution: registry entry, namespace expression, referent class, scheme version and registration status", "Lexical form: grammar, character repertoire, length, case rules, internal prefix structure, check character systems", "Equivalence: canonical form, scheme-specific normalization, permitted and forbidden comparison transformations", "Registration authority, mandate instrument, oversight body and accreditation of issuers", "Sub-namespace delegation, prefix exclusivity, change controller and revocation of delegation", "Allocation policy (private use, experimental, first come first served, expert review, specification required, hierarchical)", "Assignment records binding an identifier to a referent, with assigner, evidence and effective period", "Identifier state vocabulary and permitted transitions including deprecation, retirement, annulment and transfer", "Reuse, reassignment, quarantine, supersession, split and merge rules", "Namespace capacity, consumption and exhaustion planning", "Resolution services, protocols, coverage and the separation of identification from dereference", "Persistence commitments, tombstone behaviour and custody transfer", "Cross-scheme mapping assertions with relation type, evidence and quality", "Carriage of scheme identity alongside an identifier value in consuming models", "Collision, squatting, alias and drift detection", "Conformance evidence, defect rates and audit", "Privacy classification of identifier values and disclosure risk", "Legal mandate, licensing of registry and crosswalk data, and succession planning" ], "out_of_scope": [ "The referent itself - the person, organization, product, document, dataset or concept that an identifier denotes belongs to the model of that thing", "Identity proofing, authenticator binding, authentication and federation - an identifier is a label, not a credential", "Authorization and access control decisions taken on the basis of an identifier", "Cryptographic key management, verification methods and signature suites used by self-certifying identifier methods", "Organization master data for registration authorities, issuers and resolver operators beyond their mandate role", "Semantic definition of concepts in a controlled vocabulary; only the notation and its uniqueness are in scope here", "Transport, DNS operations, network routing and hosting of resolver infrastructure", "Record linkage and probabilistic entity resolution techniques used to reconcile records that lack a shared identifier", "Storage and interface projections: JSON, YAML, Markdown, HTML, Git, MCP and MongoDB are renderings, not semantics" ], "boundary_notes": [ { "neighbor": "Digital identity and authentication model", "distinction": "NIST SP 800-63-4 separates resolution of a subject, validation of evidence, creation of a subscriber account and binding of authenticators; this model covers only the label and its governance, never the proof that a claimant is the entity the label denotes. An identifier must never be treated as an authenticator.", "source_refs": [ "SRC-017" ] }, { "neighbor": "Controlled vocabulary / concept scheme model", "distinction": "A SKOS concept scheme governs meaning and is deliberately open-boundaried; an identifier scheme governs denotation and uniqueness of a string over referents. skos:notation is the single overlap point: the notation string is in scope here, the concept it labels is not. Code lists such as ISO 3166 sit ambiguously across this line and are recorded as an unresolved boundary.", "source_refs": [ "SRC-011" ] }, { "neighbor": "Organization model", "distinction": "Registration authorities, oversight committees, local operating units and resolver operators are organizations; only the mandate, accreditation status and change-controller role are modelled here, by reference. GLEIF, the Regulatory Oversight Committee and accredited issuers illustrate the three distinct roles.", "source_refs": [ "SRC-014", "SRC-020" ] }, { "neighbor": "Service and endpoint model", "distinction": "RFC 3986 section 1.2.2 states that a URI provides identification only and that access is neither guaranteed nor implied; resolver endpoints, protocols and service levels are described here as declared properties of the scheme, while the operational service belongs to a service model.", "source_refs": [ "SRC-002", "SRC-007" ] }, { "neighbor": "URI scheme registry / protocol registry model", "distinction": "BCP 35 governs the registration of URI scheme names as protocol elements with permanent, provisional or historical status; that registry is itself an identifier scheme instance under this model, not a separate meta-layer. Registration of a scheme name is distinguished from allocation of identifiers under it.", "source_refs": [ "SRC-004", "SRC-003" ] }, { "neighbor": "Privacy and data protection model", "distinction": "GDPR Article 4(1) makes an identification number or online identifier a route to identifiability, and Article 87 leaves national identification numbers to Member State law; this model records the classification and disclosure risk of identifier values, while lawful basis, impact assessment and data subject rights belong to the privacy model.", "source_refs": [ "SRC-018" ] }, { "neighbor": "Agreement and licensing model", "distinction": "Registration contracts, resolution service terms and bulk crosswalk licences are agreements; this model records only their existence, the obligations they impose on registrants and the continuity commitments they encode.", "source_refs": [ "SRC-014", "SRC-021" ] } ] }, "sources": [ { "id": "SRC-001", "title": "RFC 8141: Uniform Resource Names (URNs)", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc8141.html", "version_or_date": "RFC 8141, Proposed Standard, April 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:05:00Z", "relevance": "Normative source for namespace identifier syntax, URN-equivalence, formal versus informal namespaces, the non-reassignment commitment expected of registrants, and the mandatory registration template fields covering purpose, syntax, assignment, security and privacy, interoperability and resolution." }, { "id": "SRC-002", "title": "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc3986.html", "version_or_date": "STD 66, RFC 3986, January 2005", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:06:00Z", "relevance": "Normative source for the four-level comparison ladder, syntax-based normalization, scheme definition requirements, the deprecation of a strict URN/URL partition, and the statement that identification does not imply access." }, { "id": "SRC-003", "title": "RFC 8126: Guidelines for Writing an IANA Considerations Section in RFCs", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc8126.html", "version_or_date": "BCP 26, RFC 8126, June 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:07:00Z", "relevance": "Definitive catalogue of allocation policies (Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, Specification Required, RFC Required, IETF Review, Standards Action, IESG Approval), required registry fields, change control, reserved value status terms and deprecation of entries." }, { "id": "SRC-004", "title": "RFC 7595: Guidelines and Registration Procedures for URI Schemes", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc7595.html", "version_or_date": "BCP 35, RFC 7595, June 2015", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:08:00Z", "relevance": "Source for scheme registration status values (permanent, provisional, historical), the registration template including change controller, demonstrable-utility and anti-squatting guidance, and interoperability disclosure requirements." }, { "id": "SRC-005", "title": "RFC 5646: Tags for Identifying Languages", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc5646.html", "version_or_date": "BCP 47, RFC 5646, September 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:09:00Z", "relevance": "Strongest available normative model of registry stability: Type, Subtag, Tag and Added fields must not change; subtags are never removed even when the upstream source standard withdraws or reassigns a code; Deprecated and Preferred-Value fields carry supersession instead." }, { "id": "SRC-006", "title": "RFC 9562: Universally Unique IDentifiers (UUIDs)", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc9562.html", "version_or_date": "RFC 9562, Proposed Standard, May 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:10:00Z", "relevance": "Source for authority-free identifier generation, version and variant bits as structural validity checks, lexical representation, time-ordered sortability, timestamp source requirements and the obligation to analyse collision consequences." }, { "id": "SRC-007", "title": "RFC 3650: Handle System Overview", "organization": "Internet Engineering Task Force / Corporation for National Research Initiatives", "url": "https://www.rfc-editor.org/rfc/rfc3650.html", "version_or_date": "RFC 3650, Informational, November 2003", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:11:00Z", "relevance": "Source for a two-part naming authority / local name namespace, hierarchical naming authority delegation, the Global Handle Registry and Local Handle Services, typed and indexed handle values with per-value administration, and the separation of identifier from location." }, { "id": "SRC-008", "title": "Uniform Resource Names (URN) Namespaces registry", "organization": "Internet Assigned Numbers Authority", "url": "https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml", "version_or_date": "IANA protocol registry, last updated 2026-07-28", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:12:00Z", "relevance": "Working example of a registry of identifier schemes: namespace, template and reference columns, Expert Review under RFC 8141 with a standards-organization fast track, and the separation of formal from informal namespace listings." }, { "id": "SRC-009", "title": "Architecture of the World Wide Web, Volume One", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/webarch/", "version_or_date": "W3C Recommendation, 15 December 2004", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:13:00Z", "relevance": "Source for the good practices on assigning distinct identifiers to distinct resources, avoiding aliases, consistent character-by-character reference, reusing existing schemes, and the opacity rule that agents should not infer properties of a referent from its identifier." }, { "id": "SRC-010", "title": "Namespaces in XML 1.0 (Third Edition)", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/xml-names/", "version_or_date": "W3C Recommendation, 8 December 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:14:00Z", "relevance": "Counterexample source for equivalence: namespace names are compared as identical character sequences, case-sensitively, with no percent-escaping done or undone; dereference is explicitly not a goal; prefixes are local aliases that must not travel beyond the containing document." }, { "id": "SRC-011", "title": "SKOS Simple Knowledge Organization System Reference", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/skos-reference/", "version_or_date": "W3C Recommendation, 18 August 2009", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:15:00Z", "relevance": "Source for notation as a typed literal identifying a concept within a scheme, for scheme membership without closed boundaries, and for the five mapping relations including the deliberate non-transitivity of closeMatch to stop errors compounding across chained crosswalks." }, { "id": "SRC-012", "title": "Decentralized Identifiers (DIDs) v1.1", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/did-1.1/", "version_or_date": "Version 1.1, W3C Technical Report series, retrieved 2026-08-22", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:16:00Z", "relevance": "Source for method-scoped syntax, the requirement that every method specify create, resolve, update and deactivate operations, resolution versus dereferencing, and a design that displaces rather than removes the registration authority function." }, { "id": "SRC-013", "title": "FHIR Data Types: Identifier", "organization": "Health Level Seven International", "url": "https://www.hl7.org/fhir/datatypes.html", "version_or_date": "FHIR Release 5 (v5.0.0), normative datatype", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:17:00Z", "relevance": "Best available normative carriage pattern: system as an absolute namespace URI, value unique within that system, plus use (a modifier element), type, validity period and assigner - the exact shape a consuming model needs when it mixes in an identifier." }, { "id": "SRC-014", "title": "Introducing the Legal Entity Identifier (LEI)", "organization": "Global Legal Entity Identifier Foundation", "url": "https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei", "version_or_date": "Retrieved 2026-08-22; scheme standardised as ISO 17442", "source_type": "registry", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:18:00Z", "relevance": "Live example of a three-tier governance model (oversight committee, foundation administrator, accredited issuing units), an issuer-prefixed fixed-length code with check digits, a renewal obligation, an explicit registration status vocabulary and an active data quality programme." }, { "id": "SRC-015", "title": "DataCite Metadata Schema 4.6", "organization": "DataCite e.V.", "url": "https://datacite-metadata-schema.readthedocs.io/en/4.6/", "version_or_date": "Version 4.6, 2024", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:19:00Z", "relevance": "Source for mandatory registration metadata attached to an assignment, for alternateIdentifier as a place to carry other schemes, and for a relation vocabulary that expresses supersession (IsIdenticalTo, IsNewVersionOf, IsPreviousVersionOf, Obsoletes, IsVariantFormOf)." }, { "id": "SRC-016", "title": "FAIR Principles", "organization": "GO FAIR International Support and Coordination Office", "url": "https://www.go-fair.org/fair-principles/", "version_or_date": "Retrieved 2026-08-22", "source_type": "scientific", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-22T09:20:00Z", "relevance": "Community requirement statements used only as demand-side evidence: F1 globally unique and persistent identifier, F3 metadata explicitly include the identifier, A1 retrievable by identifier over a standardised protocol, A2 metadata accessible even when the data are no longer available." }, { "id": "SRC-017", "title": "NIST Special Publication 800-63-4: Digital Identity Guidelines", "organization": "National Institute of Standards and Technology", "url": "https://pages.nist.gov/800-63-4/sp800-63.html", "version_or_date": "SP 800-63-4, 2025", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:21:00Z", "relevance": "Boundary source separating resolution of a subject and creation of a subscriber account from identity proofing, authenticator binding, authentication and federation - the basis for excluding credential semantics from this model." }, { "id": "SRC-018", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng", "version_or_date": "OJ L 119, 4 May 2016; ELI http://data.europa.eu/eli/reg/2016/679/oj", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:22:00Z", "relevance": "Legal source making an identification number or online identifier a route to identifiability under Article 4(1), defining pseudonymisation in Article 4(5), treating re-identifiable data as personal under Recital 26, naming device and cookie identifiers in Recital 30, and reserving national identification numbers to Member State law under Article 87." }, { "id": "SRC-019", "title": "The ARK Identifier Scheme (draft-kunze-ark)", "organization": "IETF Datatracker / ARK Alliance", "url": "https://datatracker.ietf.org/doc/draft-kunze-ark/", "version_or_date": "Internet-Draft, retrieved 2026-08-22; not an IETF standard", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-22T09:23:00Z", "relevance": "Richest available treatment of persistence as a service commitment rather than a syntactic property, of a name-assigning-authority registry, of an ordered lexical normalization procedure including hyphen insignificance, of check characters over a defined check zone, and of policy inflections that return permanence declarations." }, { "id": "SRC-020", "title": "ITU-T Recommendation X.660 | ISO/IEC 9834-1: Procedures for the operation of object identifier registration authorities", "organization": "International Telecommunication Union - Telecommunication Standardization Sector", "url": "https://www.itu.int/rec/T-REC-X.660/en", "version_or_date": "X.660 (07/2011), in force", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T09:24:00Z", "relevance": "Authority for the existence of formal procedures governing object identifier registration authorities and the top arcs of the international object identifier tree; cited only at the level the published abstract supports, since the full text was not retrievable." }, { "id": "SRC-021", "title": "DOI Handbook", "organization": "DOI Foundation (International DOI Foundation)", "url": "https://www.doi.org/the-identifier/resources/handbook/", "version_or_date": "December 2025 edition; under review against ISO 26324:2022", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:25:00Z", "relevance": "First-party description of a scheme in which a unique registrant prefix combined with a registrant-chosen suffix separated by a forward slash permits decentralised allocation, the name is case-insensitive over a wide graphic character repertoire, and a registration agency network operates under a single registration authority." }, { "id": "SRC-022", "title": "Can a GTIN be reused? (GS1 Global Office support knowledge base)", "organization": "GS1 AISBL", "url": "https://support.gs1.org/support/solutions/articles/43000734390-can-a-gtin-be-reused-", "version_or_date": "Retrieved 2026-08-22; cites GS1 General Specifications section 4.2.5 and the GTIN Management Standard", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T09:26:00Z", "relevance": "Decisive counterexample to a universal non-reuse rule: an all-sector non-reallocation rule took effect after December 2018, but identifiers assigned to never-produced items may be reused twelve months after catalogue deletion, and withdrawn-then-reintroduced items retain their original identifier." }, { "id": "SRC-023", "title": "ISO 6523 ICD list (Peppol BIS Billing 3.0 code list)", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/", "version_or_date": "Peppol BIS Billing 3.0, May 2026 release", "source_type": "classifier", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-22T09:27:00Z", "relevance": "Operational rendering of a registry of identifier schemes: numeric scheme designators with scheme name, notes on use and issuing agency, used to name which scheme an organization identifier belongs to in cross-border electronic invoicing." }, { "id": "SRC-024", "title": "Uniform Resource Identifier (URI) Schemes", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml", "version_or_date": "Last Updated 2026-08-13", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "Authoritative live register of permanent, provisional and historical URI schemes with status, references, well-known URI support and designated experts." }, { "id": "SRC-025", "title": "Decentralized Identifiers (DIDs) v1.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/did-core/", "version_or_date": "W3C Recommendation, 19 July 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "DID method as a scheme, create/resolve/update/deactivate operations, DID controller versus subject, versionId and versionTime resolution, and explicit contrast with non-resolvable UUIDs." }, { "id": "SRC-026", "title": "ISO 26324:2025 Information and documentation — Digital object identifier system", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/88862.html", "version_or_date": "ISO 26324:2025, Edition 3, 2025-03", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "DOI syntax, assignment, uniqueness, persistence, granularity, resolution functional component, system metadata, administration by a Registration Authority, and normative relationship to other identifier schemes without replacing them." }, { "id": "SRC-027", "title": "ISO/IEC 11179-1:2023 Information technology — Metadata registries (MDR) — Part 1: Framework", "organization": "ISO/IEC JTC 1/SC 32", "url": "https://www.iso.org/standard/78914.html", "version_or_date": "ISO/IEC 11179-1:2023, Edition 4, 2023-01", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "Identifier versus linguistically neutral name, scoped identifier within a namespace, registration as identification plus provenance plus quality monitoring, and mapping among registry items." }, { "id": "SRC-028", "title": "ISO/IEC 6523-1:2023 Information technology — Structure for the identification of organizations and organization parts — Part 1: Identification of organization identification schemes", "organization": "ISO/IEC JTC 1/SC 32", "url": "https://webstore.iec.ch/en/publication/87933", "version_or_date": "ISO/IEC 6523-1:2023, Edition 2.0, 2023-08-14", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "Structure for globally unambiguous organisation identification schemes, International Code Designator, and separation of scheme identification from the registration procedure in Part 2." }, { "id": "SRC-029", "title": "ISO 24619:2011 Language resource management — Persistent identification and sustainable access (PISA)", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/37333.html", "version_or_date": "ISO 24619:2011, confirmed 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "PID framework requirements: resolution of one PID to multiple URIs or services, associated metadata, security of PID-to-URI mappings, persistence and granularity of references." }, { "id": "SRC-030", "title": "HL7 FHIR R5 Datatype Identifier", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/datatypes-definitions.html#Identifier", "version_or_date": "FHIR v5.0.0, 2023", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "Computational identifier tuple of system namespace URI plus value, use codes usual/official/temp/secondary/old, validity period, assigner organisation, and check-digit placement rules." }, { "id": "SRC-031", "title": "DOI Handbook", "organization": "DOI Foundation", "url": "https://www.doi.org/doi-handbook/html/index.html", "version_or_date": "DOI Handbook 2025, updated 2025-12-10", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "Operational Handle-based resolution, Global versus Local Handle Service, DOI record types, prefix delegation and RA administration implementing ISO 26324." }, { "id": "SRC-032", "title": "ARK NAANs and systems", "organization": "ARK Alliance / California Digital Library", "url": "https://arks.org/about/ark-naans-and-systems/", "version_or_date": "Published 2021-01-23, accessed 2026-08-22", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "Name Assigning Authority Number registry, Name Mapping Authority versus assigning authority, collision-free organisational namespaces, and N2T as a multi-scheme resolver." }, { "id": "SRC-033", "title": "GS1 check digit calculator and identification-key integrity", "organization": "GS1", "url": "https://www.gs1.org/services/check-digit-calculator", "version_or_date": "GS1 first-party service documentation, accessed 2026-08-22", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T18:00:00Z", "relevance": "Check digit as last digit of fixed-length numeric GS1 keys, exceptions for CPID and GIAI, and GMN check-character pair rather than a single check digit." } ], "structure": { "bundles": [ { "id": "scheme-constitution", "name": "Scheme Constitution and Lexical Form", "description": "What the scheme is, which strings it admits, when two strings denote the same thing, and how much meaning the string is allowed to carry.", "rationale": "Nothing can be allocated, resolved or mapped until the scheme itself is identifiable and the set of well-formed identifiers is decidable. RFC 8141 makes a syntax statement and equivalence rules mandatory in a namespace registration; RFC 3986 makes comparison a graded, scheme-dependent operation; W3C web architecture makes distinctness of identifiers a first constraint. These are prerequisites, not attributes.", "source_refs": [ "SRC-001", "SRC-002", "SRC-009" ], "layers": [ { "id": "scheme-identity-and-scope", "name": "Scheme Identity and Scope", "description": "The scheme as a first-class referent: its registry key, namespace expression, class of referents, version and registration status.", "source_refs": [ "SRC-001", "SRC-008", "SRC-004", "SRC-023" ], "findings": [ { "id": "scheme-identity-record", "name": "Scheme identity, namespace expression and referent class", "description": "An identifier scheme is itself a referent that must be identifiable, scoped and statused before any identifier under it can be interpreted. Its identity comes from an entry in a governing registry (an IANA URN namespace identifier, a URI scheme name, an ISO 6523 code designator, a DID method name), and its scope is the declared class of referents it may name. The namespace expression is the token a consuming model carries next to the value so that the value can be interpreted at all.", "source_refs": [ "SRC-001", "SRC-008", "SRC-004", "SRC-023", "SRC-013" ], "questions": [ { "id": "q-scheme-registry-key", "text": "Which authoritative registry entry establishes this scheme, and under what key?", "kind": "identity", "answer_data": [ "Governing registry name and URL", "Registration key as issued (namespace identifier, scheme name, code designator, method name)", "Registration date and reference document" ] }, { "id": "q-scheme-referent-class", "text": "What class of referents may be named under this scheme, and what is explicitly excluded?", "kind": "classification", "answer_data": [ "Referent class statement", "Explicit exclusions", "Representative in-scope and out-of-scope examples" ] }, { "id": "q-scheme-namespace-expression", "text": "What namespace expression must accompany a value of this scheme when it is carried inside another model?", "kind": "interoperability", "answer_data": [ "Absolute namespace URI", "Alternative tokens such as namespace identifier or numeric code designator", "Statement of which token is canonical for exchange" ] }, { "id": "q-scheme-version-effect", "text": "Is the scheme versioned, and does a version change alter the meaning of identifiers already assigned?", "kind": "temporal", "answer_data": [ "Scheme version label", "Version effective date as an RFC 3339 timestamp", "Backward-compatibility statement for prior assignments" ] }, { "id": "q-scheme-status", "text": "What is the scheme's registration status and when did that status last change?", "kind": "state", "answer_data": [ "Status value such as permanent, provisional, historical, formal or informal", "Status effective timestamp", "Reason for the most recent status change" ] } ], "data_elements": [ { "id": "de-scheme-key", "name": "Scheme registry key", "description": "The key under which the governing registry lists this scheme; the primary identity of the scheme record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-004" ] }, { "id": "de-scheme-namespace-uri", "name": "Scheme namespace expression", "description": "An absolute URI or equivalent token that establishes the namespace within which values are unique.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-001", "SRC-023" ] }, { "id": "de-scheme-referent-class", "name": "Referent class statement", "description": "Declared class of things that may be named under the scheme, with exclusions.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-scheme-version", "name": "Scheme version label", "description": "Version designator of the scheme specification currently in force.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-scheme-status", "name": "Scheme registration status", "description": "Coded status of the scheme's registration in its governing registry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-001" ] }, { "id": "de-scheme-status-since", "name": "Status effective time", "description": "Time from which the current registration status applies.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "scheme-registration-record", "name": "Scheme registration record", "description": "The registry entry constituting the scheme, holding its key, namespace expression, referent class, status, reference document and change controller.", "media_or_form": [ "structured registry entry", "published registry listing" ], "serial": false, "identity_strategy": "Registry key issued by the governing registry; where no registry exists, the declared namespace URI; failing both, a Dimension-assigned UUID or ULID recorded as locally scoped.", "source_refs": [ "SRC-008", "SRC-004", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "id": "lexical-form-and-validation", "name": "Lexical Form and Validation", "description": "The grammar, repertoire and self-checking machinery that decide whether a candidate string is a well-formed identifier of this scheme.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006", "SRC-019" ], "findings": [ { "id": "identifier-syntax-grammar", "name": "Identifier grammar, repertoire and internal structure", "description": "The decidable definition of a well-formed identifier: a formal grammar, the permitted character repertoire and encoding, length bounds, case treatment, and which substrings are structurally significant. RFC 8141 requires a syntax statement in every namespace registration and constrains namespace identifiers to a bounded alphanumeric pattern; RFC 3986 requires a scheme's own syntax to remain within the generic grammar; DOI names divide at a forward slash into an issuer prefix and a registrant-chosen suffix; the LEI is a fixed twenty-character code whose leading characters denote the issuing unit.", "source_refs": [ "SRC-001", "SRC-002", "SRC-021", "SRC-014", "SRC-006" ], "questions": [ { "id": "q-syntax-expression", "text": "What machine-checkable expression defines a well-formed identifier of this scheme?", "kind": "constraint", "answer_data": [ "Formal grammar or pattern expression", "Notation used and its version", "Location of the authoritative expression in the specification" ] }, { "id": "q-syntax-repertoire", "text": "Which characters and encodings are permitted, and how is case treated?", "kind": "constraint", "answer_data": [ "Permitted character repertoire", "Encoding rules including any escaping", "Case sensitivity statement" ] }, { "id": "q-syntax-structure", "text": "Which substrings of an identifier are structurally significant, and what do they delimit?", "kind": "composition", "answer_data": [ "Named components and their delimiters", "Which component denotes the issuing authority", "Whether component boundaries are fixed-width or delimiter-driven" ] }, { "id": "q-syntax-length", "text": "What minimum and maximum lengths apply, and are they enforced at assignment or only at validation?", "kind": "constraint", "answer_data": [ "Minimum and maximum length", "Enforcement point", "Behaviour on out-of-range input" ] }, { "id": "q-syntax-legacy", "text": "How are historical values that fail the current grammar handled?", "kind": "exception", "answer_data": [ "Count and examples of non-conforming legacy values", "Tolerance or quarantine policy", "Migration or annotation approach" ] } ], "data_elements": [ { "id": "de-syntax-expression", "name": "Syntax expression", "description": "Formal grammar or pattern that a candidate string must satisfy.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-character-repertoire", "name": "Character repertoire and encoding rule", "description": "Permitted characters, encoding and escaping rules for identifier values.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-021" ] }, { "id": "de-case-sensitivity", "name": "Case sensitivity flag", "description": "Whether identifier values of this scheme are case-sensitive.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-010", "SRC-021" ] }, { "id": "de-length-bounds", "name": "Length bounds", "description": "Minimum and maximum permitted length of an identifier value.", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] }, { "id": "de-structural-component", "name": "Structural component definition", "description": "A named component of the identifier with its delimiter, position and meaning.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021", "SRC-007", "SRC-014" ] } ], "artifacts": [ { "id": "syntax-specification", "name": "Identifier syntax specification", "description": "The clause or document holding the authoritative grammar, repertoire, length and structure rules for the scheme.", "media_or_form": [ "specification clause", "formal grammar expression" ], "serial": false, "identity_strategy": "Scheme registry key plus specification version; the grammar is never identified by date alone.", "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "syntax-test-vector-set", "name": "Syntax test vector set", "description": "Paired accept and reject examples that let an implementation prove it applies the grammar correctly, including boundary and legacy cases.", "media_or_form": [ "test-vector collection", "tabular dataset" ], "serial": true, "identity_strategy": "Scheme registry key plus test-set version; serial members numbered in issue order.", "source_refs": [ "SRC-004", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "check-character-and-validation", "name": "Check character systems and what validity proves", "description": "Many schemes carry a self-checking element - LEI check digits, an ARK check character computed over a defined check zone, or the version and variant bits of a UUID - that detects transcription error. This finding separates three distinct claims that are routinely confused: the string is well-formed, the string passes its internal check, and the string has actually been assigned to a referent by the authority. Only the third is evidence of existence.", "source_refs": [ "SRC-014", "SRC-019", "SRC-006", "SRC-001" ], "questions": [ { "id": "q-check-algorithm", "text": "What check character algorithm applies, and over which part of the string is it computed?", "kind": "measurement", "answer_data": [ "Algorithm name and reference", "Definition of the check zone", "Position and width of the check element" ] }, { "id": "q-check-meaning", "text": "What does a passing check prove, and what does it not prove?", "kind": "evidence", "answer_data": [ "Detected error classes", "Explicit statement that a passing check does not prove assignment", "Residual undetected error rate if published" ] }, { "id": "q-validity-authority", "text": "Which authority must be consulted to confirm that a well-formed identifier has actually been assigned?", "kind": "authority", "answer_data": [ "Confirming registry or service", "Query interface reference", "Expected latency and coverage of the confirmation" ] }, { "id": "q-check-absent", "text": "If the scheme has no check element, what compensating control detects transcription error?", "kind": "quality", "answer_data": [ "Compensating control description", "Observed or estimated transcription error rate", "Point in the workflow where the control is applied" ] } ], "data_elements": [ { "id": "de-check-algorithm", "name": "Check character algorithm", "description": "Named algorithm used to compute the scheme's check element, with its reference.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-019" ] }, { "id": "de-check-zone", "name": "Check zone definition", "description": "The substring over which the check element is computed.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "de-validity-level", "name": "Asserted validity level", "description": "Whether a value is asserted as well-formed only, check-passing, or registry-confirmed as assigned.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-014" ] }, { "id": "de-confirmation-source", "name": "Assignment confirmation source", "description": "Reference to the authority or service that can confirm an assignment exists.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-008" ] } ], "artifacts": [ { "id": "validation-conformance-report", "name": "Validation conformance report", "description": "Record of a validation run over a population of values, reporting well-formedness, check-element failures and unconfirmed assignments separately.", "media_or_form": [ "structured report", "tabular dataset" ], "serial": true, "identity_strategy": "Scheme registry key plus run start timestamp in RFC 3339; serial number assigned in run order.", "source_refs": [ "SRC-014", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "equivalence-and-canonical-form", "name": "Equivalence and Canonical Form", "description": "When two strings denote the same referent, which transformations preserve identity, and which comparison level a consumer is entitled to apply.", "source_refs": [ "SRC-002", "SRC-001", "SRC-010", "SRC-019" ], "findings": [ { "id": "equivalence-and-normalization-rules", "name": "Scheme-specific equivalence and normalization rules", "description": "Comparison is not a generic operation. RFC 3986 sets out a ladder from simple string comparison through syntax-based and scheme-based normalization to protocol-based normalization, with each rung raising both true-positive and false-positive rates. RFC 8141 requires case normalization of the scheme token and namespace identifier while forbidding percent-decoding and requiring optional components to be ignored. XML namespace names are compared as identical character sequences with no escaping done or undone. ARK normalization removes the resolver host, lowercases the authority number and treats hyphens as insignificant. A single global normalizer applied across schemes will merge distinct referents.", "source_refs": [ "SRC-002", "SRC-001", "SRC-010", "SRC-019", "SRC-021" ], "questions": [ { "id": "q-canonical-form", "text": "What is the canonical form of an identifier of this scheme, and how is it derived?", "kind": "definition", "answer_data": [ "Canonical form definition", "Ordered normalization procedure", "Worked example from raw input to canonical output" ] }, { "id": "q-equivalence-transforms", "text": "Which transformations preserve identity for this scheme and which must never be applied?", "kind": "constraint", "answer_data": [ "Permitted transformations", "Forbidden transformations with the harm each would cause", "Handling of optional or trailing components" ] }, { "id": "q-comparison-level", "text": "Which comparison level is a consumer entitled to rely on without contacting the authority?", "kind": "constraint", "answer_data": [ "Highest safe comparison level", "Operations requiring authority contact", "Known false-positive and false-negative modes" ] }, { "id": "q-storage-form", "text": "Which form is stored and indexed, and is the form as received also retained?", "kind": "quality", "answer_data": [ "Stored form policy", "Whether the as-received form is preserved", "Index and collation rules applied" ] }, { "id": "q-alias-policy", "text": "Does the scheme permit more than one identifier for the same referent, and how are aliases declared?", "kind": "relationship", "answer_data": [ "Alias permission statement", "Preferred or canonical identifier designation", "Mechanism for declaring an alias relationship" ] } ], "data_elements": [ { "id": "de-canonical-form-rule", "name": "Canonicalization rule set", "description": "Ordered set of transformations producing the canonical form of an identifier value.", "value_kind": "collection", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-001", "SRC-019" ] }, { "id": "de-canonical-value", "name": "Canonical identifier value", "description": "The identifier value after the scheme's canonicalization rules have been applied.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-as-received-value", "name": "As-received identifier value", "description": "The identifier value exactly as supplied, retained for provenance and dispute resolution.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-comparison-level", "name": "Permitted comparison level", "description": "The highest comparison rung a consumer may apply without consulting the authority.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-preferred-identifier-flag", "name": "Preferred identifier flag", "description": "Marks which of several identifiers for one referent is preferred for outward reference.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-005" ] } ], "artifacts": [ { "id": "canonicalization-test-vector-set", "name": "Canonicalization test vector set", "description": "Input and expected-canonical-output pairs, including pairs that must remain distinct, used to prove a normalizer matches the scheme's rules.", "media_or_form": [ "test-vector collection", "tabular dataset" ], "serial": true, "identity_strategy": "Scheme registry key plus rule-set version; serial members numbered in issue order.", "source_refs": [ "SRC-002", "SRC-001", "SRC-019" ] } ], "inline_only_rationale": null } ] }, { "id": "semantic-transparency-and-opacity", "name": "Semantic Transparency and Opacity", "description": "How much the identifier string is permitted to say about its referent, and what that disclosure costs.", "source_refs": [ "SRC-009", "SRC-019", "SRC-002", "SRC-018" ], "findings": [ { "id": "opacity-and-embedded-semantics", "name": "Opacity policy and embedded semantics", "description": "W3C web architecture advises that agents should not infer properties of a referent from its identifier, and ARK strongly encourages semantic opacity so that names survive changes in the world. Yet delegated-prefix schemes deliberately embed the issuing authority in the string, which is exactly what makes decentralised allocation work. This finding records what the scheme permits to be inferred, what must never be inferred, and what the structure discloses to an observer who was never meant to know it.", "source_refs": [ "SRC-009", "SRC-019", "SRC-002", "SRC-014", "SRC-018" ], "questions": [ { "id": "q-inference-permitted", "text": "What may an agent legitimately infer from the structure of an identifier of this scheme?", "kind": "interoperability", "answer_data": [ "Permitted inferences with the component each rests on", "Specification clause authorising each inference", "Stability guarantee attached to the inference" ] }, { "id": "q-inference-forbidden", "text": "What must an agent never infer from an identifier value, even when the pattern appears to support it?", "kind": "constraint", "answer_data": [ "Forbidden inferences", "Concrete failure case for each", "Whether the specification states the prohibition explicitly" ] }, { "id": "q-semantic-leakage", "text": "What does the identifier disclose to an observer who holds only the string?", "kind": "access", "answer_data": [ "Disclosed attributes such as issuer, sequence position, creation time or category", "Assessment of whether disclosure is intended", "Mitigation where disclosure is unintended" ] }, { "id": "q-semantic-drift", "text": "If an embedded attribute of the referent changes, does the identifier change?", "kind": "lifecycle", "answer_data": [ "Policy on identifier change following referent change", "Examples of attribute changes that do and do not trigger reassignment", "Consequence for existing references" ] } ], "data_elements": [ { "id": "de-opacity-class", "name": "Opacity class", "description": "Whether identifiers are fully opaque, issuer-transparent, or semantically loaded.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-019" ] }, { "id": "de-permitted-inference", "name": "Permitted inference statement", "description": "An inference a consumer may draw from identifier structure, with its authorising clause.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-014" ] }, { "id": "de-disclosure-risk-note", "name": "Structural disclosure note", "description": "What an identifier value reveals about its referent or its creation to a bare observer.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-006" ] } ], "artifacts": [ { "id": "semantic-disclosure-statement", "name": "Semantic disclosure statement", "description": "Published statement of what the scheme's identifiers do and do not encode, written for consumers who must decide whether to parse them.", "media_or_form": [ "published statement", "structured record" ], "serial": false, "identity_strategy": "Scheme registry key plus statement version and RFC 3339 issue timestamp.", "source_refs": [ "SRC-009", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "authority-and-registration", "name": "Authority, Delegation and Registration Policy", "description": "Who is mandated to run the scheme, how that mandate is sub-delegated, under what policy identifiers and sub-namespaces are handed out, and what the registration record must contain.", "rationale": "RFC 8141 makes organizational stability, competence and a non-reassignment commitment the qualifying conditions for a formal namespace; RFC 8126 supplies the exhaustive vocabulary of allocation policies; ITU-T X.660 establishes that registration authorities operate under published procedures; GLEIF demonstrates the separation of oversight, administration and issuance in practice. Authority is therefore a distinct concern from syntax and from assignment.", "source_refs": [ "SRC-001", "SRC-003", "SRC-020", "SRC-014" ], "layers": [ { "id": "registration-authority-and-mandate", "name": "Registration Authority and Mandate", "description": "The party that holds the scheme mandate, the instrument granting it, the body that oversees it, and the evidence of its fitness to endure.", "source_refs": [ "SRC-020", "SRC-014", "SRC-001", "SRC-021" ], "findings": [ { "id": "authority-mandate-and-accreditation", "name": "Mandate, oversight and issuer accreditation", "description": "A scheme's credibility rests on a named party holding an identifiable mandate. RFC 8141 asks a formal-namespace registrant to demonstrate organizational stability, competence in assignment and a commitment not to reassign. ITU-T X.660 establishes published procedures for object identifier registration authorities. The LEI system separates three roles that are often collapsed: a regulatory oversight committee, a foundation acting as administrator, and accredited local operating units that actually issue. The DOI system likewise separates a single registration authority from a network of registration agencies.", "source_refs": [ "SRC-001", "SRC-020", "SRC-014", "SRC-021", "SRC-023" ], "questions": [ { "id": "q-mandate-holder", "text": "Who holds the mandate for this scheme, and under what instrument was it granted?", "kind": "authority", "answer_data": [ "Mandated party with a reference to the organization record", "Instrument type such as international standard, statute, charter or registry designation", "Mandate start date and any expiry" ] }, { "id": "q-oversight-body", "text": "Which body oversees the mandate holder, and what powers does it hold?", "kind": "authority", "answer_data": [ "Oversight body reference", "Enumerated powers including accreditation and withdrawal", "Reporting cadence" ] }, { "id": "q-issuer-accreditation", "text": "How are issuing bodies accredited, and how is accreditation withdrawn?", "kind": "process", "answer_data": [ "Accreditation criteria and process", "Current accredited issuer list reference", "Withdrawal grounds and effect on already-issued identifiers" ] }, { "id": "q-stability-evidence", "text": "What evidence supports the mandate holder's ability to sustain the scheme over its intended horizon?", "kind": "evidence", "answer_data": [ "Stability and competence evidence as filed", "Stated intended horizon", "Funding basis" ] }, { "id": "q-authority-failure", "text": "What happens to assignments and resolution if the mandate holder ceases to operate?", "kind": "exception", "answer_data": [ "Named successor or escrow arrangement", "Continuity commitment text", "Evidence that the arrangement has been tested" ] } ], "data_elements": [ { "id": "de-mandate-holder-ref", "name": "Mandate holder reference", "description": "Reference to the organization holding the scheme mandate.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-020", "SRC-014" ] }, { "id": "de-mandate-instrument", "name": "Mandate instrument", "description": "The standard, statute, charter or registry designation conferring the mandate.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-020", "SRC-001" ] }, { "id": "de-mandate-period", "name": "Mandate period", "description": "Start and any end time of the mandate.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-oversight-body-ref", "name": "Oversight body reference", "description": "Reference to the body supervising the mandate holder.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-accredited-issuer-ref", "name": "Accredited issuer reference", "description": "Reference to a body accredited to issue identifiers under the scheme.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-021" ] }, { "id": "de-jurisdiction-scope", "name": "Territorial or sectoral scope", "description": "The jurisdiction or sector within which the mandate is effective.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-023", "SRC-018" ] } ], "artifacts": [ { "id": "mandate-instrument-record", "name": "Mandate instrument record", "description": "Record of the instrument conferring scheme authority, its parties, scope, period and oversight arrangements.", "media_or_form": [ "governing document", "structured record" ], "serial": false, "identity_strategy": "Instrument's own official reference where one exists; otherwise scheme registry key plus mandate start timestamp.", "source_refs": [ "SRC-020", "SRC-014" ] }, { "id": "accredited-issuer-register", "name": "Accredited issuer register", "description": "List of bodies currently accredited to issue under the scheme, with accreditation state and effective dates.", "media_or_form": [ "published register", "tabular dataset" ], "serial": false, "identity_strategy": "Scheme registry key plus register edition timestamp in RFC 3339.", "source_refs": [ "SRC-014", "SRC-021" ] } ], "inline_only_rationale": null } ] }, { "id": "delegation-and-sub-namespaces", "name": "Delegation and Sub-Namespaces", "description": "How allocation authority is subdivided, whether delegation is exclusive, who controls change to a given entry, and how delegation ends.", "source_refs": [ "SRC-003", "SRC-007", "SRC-020", "SRC-021" ], "findings": [ { "id": "delegation-chain-and-change-control", "name": "Delegation chain, exclusivity and change controller", "description": "Hierarchical allocation lets delegated administrators control portions of a namespace while a higher authority manages the levels above, and RFC 8126 names it as a policy in its own right. The Handle System builds naming authorities as a dotted tree in which global uniqueness follows from a globally unique authority combined with a locally unique name. DOI achieves decentralised allocation the same way. Delegation raises questions the parent scheme must answer: is a delegated prefix exclusive against longer strings sharing its leading characters, who may change an entry once delegated, and what happens to identifiers already issued when a delegation is revoked.", "source_refs": [ "SRC-003", "SRC-007", "SRC-021", "SRC-014", "SRC-004" ], "questions": [ { "id": "q-delegation-mechanism", "text": "How is allocation authority subdivided, and what is the shape of the delegation tree?", "kind": "composition", "answer_data": [ "Delegation mechanism description", "Depth and branching rules", "Current delegation chain for a given identifier" ] }, { "id": "q-delegation-exclusivity", "text": "Is a delegated namespace portion exclusive, and does it foreclose overlapping allocations?", "kind": "constraint", "answer_data": [ "Exclusivity rule text", "Treatment of longer strings sharing a delegated prefix", "Conflict resolution procedure" ] }, { "id": "q-change-controller", "text": "Who is the change controller for a given registry entry or delegated namespace?", "kind": "ownership", "answer_data": [ "Change controller reference per entry", "Scope of changes the controller may make", "Procedure for transferring change control" ] }, { "id": "q-delegation-revocation", "text": "On what grounds can a delegation be revoked, and what becomes of identifiers already issued under it?", "kind": "lifecycle", "answer_data": [ "Revocation grounds", "Effect on outstanding assignments", "Notice period and migration path" ] }, { "id": "q-delegation-recursion", "text": "May a delegate sub-delegate further, and is the parent bound by the delegate's policy?", "kind": "authority", "answer_data": [ "Sub-delegation permission statement", "Policy inheritance rule", "Liability and audit reach of the parent" ] } ], "data_elements": [ { "id": "de-delegated-namespace", "name": "Delegated namespace portion", "description": "The prefix, arc or sub-namespace whose allocation authority has been delegated.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-003" ] }, { "id": "de-delegate-ref", "name": "Delegate reference", "description": "Reference to the party holding a delegated allocation authority.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-014" ] }, { "id": "de-delegation-exclusive", "name": "Delegation exclusivity flag", "description": "Whether the delegated portion is exclusive against overlapping allocations.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-change-controller", "name": "Change controller", "description": "Party entitled to modify a registry entry or delegated namespace record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "de-delegation-effective-period", "name": "Delegation effective period", "description": "Start and end times of a delegation.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "delegation-register", "name": "Delegation register", "description": "Register of delegated namespace portions with delegate, exclusivity, change controller and effective period.", "media_or_form": [ "published register", "tabular dataset" ], "serial": false, "identity_strategy": "Scheme registry key plus delegated namespace portion; the pair is the natural key.", "source_refs": [ "SRC-003", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "allocation-policy-and-registry-record", "name": "Allocation Policy and Registry Record", "description": "The rule by which new registrations and allocations are granted, and the fields the resulting record must carry.", "source_refs": [ "SRC-003", "SRC-001", "SRC-004", "SRC-008" ], "findings": [ { "id": "allocation-policy", "name": "Allocation policy and reserved ranges", "description": "RFC 8126 supplies the working vocabulary: Private Use and Experimental Use where nothing is recorded centrally, Hierarchical Allocation where administrators control portions, First Come First Served with no substantive review, Expert Review, Specification Required which additionally demands a permanent and readily available public specification, and the progressively stricter document-based policies. It also distinguishes Unassigned from Reserved and introduces Known Unregistered Use as a warning marker. A scheme that cannot name its policy cannot tell a consumer how much review any given identifier has had.", "source_refs": [ "SRC-003", "SRC-008", "SRC-004", "SRC-001" ], "questions": [ { "id": "q-allocation-policy-value", "text": "Which allocation policy governs new registrations under this scheme?", "kind": "authority", "answer_data": [ "Named policy value", "Clause establishing it", "Whether different ranges carry different policies" ] }, { "id": "q-designated-experts", "text": "If review is required, who performs it and against what published criteria?", "kind": "process", "answer_data": [ "Reviewer identity or role", "Published review criteria", "Appeal route against a refusal" ] }, { "id": "q-reserved-ranges", "text": "Which value ranges are reserved, private-use, experimental or otherwise withheld from allocation?", "kind": "classification", "answer_data": [ "Range boundaries with status for each", "Rationale for each reservation", "Whether reserved values may later be released" ] }, { "id": "q-policy-change", "text": "Can the allocation policy itself be changed, and by what procedure?", "kind": "process", "answer_data": [ "Amendment procedure", "Effect on registrations made under a prior policy", "Most recent amendment with its RFC 3339 timestamp" ] }, { "id": "q-unregistered-use", "text": "How does the scheme record values known to be in use without a registration?", "kind": "exception", "answer_data": [ "Marker used for known unregistered use", "Discovery and confirmation procedure", "Whether such values can be regularised" ] } ], "data_elements": [ { "id": "de-allocation-policy", "name": "Allocation policy value", "description": "The named policy governing new registrations or allocations.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-reviewer-role", "name": "Designated reviewer role", "description": "Role or party performing review where the policy requires it.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "id": "de-reserved-range", "name": "Reserved range definition", "description": "A value range withheld from ordinary allocation, with its status code.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-policy-effective-from", "name": "Policy effective time", "description": "Time from which the current allocation policy applies.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "allocation-policy-statement", "name": "Allocation policy statement", "description": "Published statement naming the allocation policy, the reviewers, the reserved ranges and the amendment procedure.", "media_or_form": [ "published statement", "specification clause" ], "serial": false, "identity_strategy": "Scheme registry key plus policy version and RFC 3339 effective timestamp.", "source_refs": [ "SRC-003", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "scheme-registration-template-record", "name": "Registration template content and entry deprecation", "description": "RFC 8141 makes a namespace registration carry purpose, syntax including equivalence rules, assignment mechanism, security and privacy analysis, interoperability conflicts, and a resolution statement, with a pointer to a stable specification. BCP 35 adds status, applications and protocols, contact and change controller. RFC 8126 further allows a registry to be closed or marked obsolete and individual entries to be deprecated with annotations preserved for history. These filed statements are the primary machine-readable evidence about a scheme and are frequently the only evidence available to a consuming agent.", "source_refs": [ "SRC-001", "SRC-004", "SRC-003", "SRC-008" ], "questions": [ { "id": "q-template-completeness", "text": "Which registration template fields were filed, and which mandatory fields are missing or empty?", "kind": "evidence", "answer_data": [ "Field-by-field completeness assessment", "Missing mandatory fields", "Date the registration was last revised" ] }, { "id": "q-permanent-specification", "text": "Where is the permanent and readily available public specification for this scheme?", "kind": "provenance", "answer_data": [ "Specification location and stable reference", "Availability terms including any paywall", "Version currently in force" ] }, { "id": "q-filed-security-privacy", "text": "What security and privacy analysis was filed with the registration?", "kind": "evidence", "answer_data": [ "Filed comparison, leakage and privacy statements", "Known gaps in the analysis", "Date of the analysis" ] }, { "id": "q-entry-deprecation", "text": "How is a registry entry deprecated or obsoleted, and what annotation survives?", "kind": "lifecycle", "answer_data": [ "Deprecation mechanism", "Annotation retained for historical entries", "Whether the registry as a whole can be closed" ] } ], "data_elements": [ { "id": "de-registration-field", "name": "Registration template field", "description": "A named field of the filed registration with its value and mandatory status.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "de-specification-reference", "name": "Permanent specification reference", "description": "Stable pointer to the scheme's public specification.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-001" ] }, { "id": "de-entry-lifecycle-status", "name": "Registry entry lifecycle status", "description": "Whether the entry is current, deprecated or obsoleted.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-registration-revised-at", "name": "Registration revision time", "description": "Time at which the registration record was last revised.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "registration-template-submission", "name": "Registration template submission", "description": "The completed registration template as filed with the governing registry, including purpose, syntax, assignment, security and privacy, interoperability and resolution statements.", "media_or_form": [ "completed template document", "structured record" ], "serial": true, "identity_strategy": "Governing registry key plus submission version; revisions numbered serially and each carrying its own RFC 3339 submission timestamp.", "source_refs": [ "SRC-001", "SRC-004", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "assignment-and-lifecycle", "name": "Assignment, State and Continuity", "description": "The act of binding an identifier to a referent, the states that binding passes through, whether a retired identifier may ever be used again, and whether the namespace will hold out.", "rationale": "RFC 8141 makes the assignment mechanism a mandatory element of a namespace registration and a non-reassignment commitment a qualifying condition; BCP 47 shows a registry that guarantees subtags are never removed and carries supersession through deprecation and preferred-value fields instead; GLEIF publishes an explicit registration status vocabulary and a renewal duty; RFC 9562 requires collision consequences to be reasoned about. Binding, state and continuity are therefore separable from syntax and from resolution.", "source_refs": [ "SRC-001", "SRC-005", "SRC-014", "SRC-006" ], "layers": [ { "id": "assignment-act-and-binding", "name": "Assignment Act and Binding", "description": "The record of who bound which identifier to which referent, when, on what evidence, and with what obligatory metadata.", "source_refs": [ "SRC-013", "SRC-001", "SRC-015", "SRC-021" ], "findings": [ { "id": "identifier-assignment-record", "name": "Assignment record: referent binding, assigner, evidence and period", "description": "The assignment is the atomic fact this model exists to support. The FHIR Identifier datatype gives the minimal shape a consumer needs: a system establishing the namespace, a value unique within it, an optional coded type, a use marker that modifies interpretation, a validity period and an assigner. DataCite shows that a registration agency may impose mandatory descriptive metadata as a condition of assignment. RFC 8141 requires the assignment mechanism and its uniqueness method to be specified. Event time and record time must be kept apart: when the binding took effect is not when the register learned of it.", "source_refs": [ "SRC-013", "SRC-015", "SRC-001", "SRC-021", "SRC-014" ], "questions": [ { "id": "q-assignment-referent", "text": "Which referent is bound by this assignment, and how is that referent itself identified?", "kind": "identity", "answer_data": [ "Referent reference with its own identifier and scheme", "Referent class", "Statement of whether the binding is exclusive to one referent" ] }, { "id": "q-assignment-assigner", "text": "Who performed the assignment, under which delegated authority?", "kind": "authority", "answer_data": [ "Assigner reference", "Delegated namespace portion used", "Authorisation basis" ] }, { "id": "q-assignment-time", "text": "When did the assignment take effect, and when was it recorded?", "kind": "temporal", "answer_data": [ "Assignment effective time in RFC 3339", "Record or ingestion time in RFC 3339", "Reason for any gap between the two" ] }, { "id": "q-assignment-evidence", "text": "What evidence supports that the referent is what the registrant claims it to be?", "kind": "evidence", "answer_data": [ "Evidence artefacts referenced", "Verification level applied", "Party that performed verification" ] }, { "id": "q-assignment-obligations", "text": "What metadata or conduct obligations does the registrant accept as a condition of assignment?", "kind": "requirement", "answer_data": [ "Mandatory metadata properties", "Update and renewal duties", "Consequence of non-compliance" ] }, { "id": "q-assignment-use", "text": "What is the intended use of this identifier relative to any others held by the same referent?", "kind": "classification", "answer_data": [ "Use marker such as official, usual, secondary, temporary or old", "Coded identifier type", "Validity period" ] } ], "data_elements": [ { "id": "de-identifier-value", "name": "Identifier value", "description": "The identifier string bound to the referent, unique within its namespace.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-001" ] }, { "id": "de-identifier-system", "name": "Identifier system", "description": "Absolute namespace URI or equivalent token establishing where the value is unique.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "de-referent-ref", "name": "Referent reference", "description": "Reference to the thing the identifier denotes.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-015" ] }, { "id": "de-assigner-ref", "name": "Assigner reference", "description": "Organization or unit that issued or manages the identifier.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "de-identifier-use", "name": "Identifier use marker", "description": "Coded purpose of this identifier for its referent; interpretation-modifying.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-assignment-effective-time", "name": "Assignment effective time", "description": "Time from which the binding is in force.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-015" ] }, { "id": "de-assignment-recorded-time", "name": "Assignment record time", "description": "Time at which the register observed or ingested the assignment.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-assignment-evidence-ref", "name": "Assignment evidence reference", "description": "Reference to evidence supporting the referent's claim.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-001" ] }, { "id": "de-assignment-validity-period", "name": "Identifier validity period", "description": "Period during which the identifier is or was valid for use.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "assignment-register", "name": "Assignment register", "description": "The authoritative register of bindings between identifiers and referents, with assigner, effective and record times, evidence and obligatory metadata.", "media_or_form": [ "authoritative register", "tabular dataset", "structured record set" ], "serial": false, "identity_strategy": "Namespace expression plus canonical identifier value as the natural key of each entry; the register itself is keyed by scheme registry key.", "source_refs": [ "SRC-013", "SRC-014", "SRC-015" ] }, { "id": "registration-metadata-record", "name": "Registration metadata record", "description": "The descriptive metadata a registration agency requires as a condition of assignment, including any alternate identifiers held by the same referent.", "media_or_form": [ "structured metadata record" ], "serial": false, "identity_strategy": "The assigned identifier itself is the record key; version by RFC 3339 revision timestamp.", "source_refs": [ "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "granularity-qualifiers-and-notations", "name": "Granularity, qualifiers and notations", "description": "ISO 26324 and ISO 24619 require explicit granularity. ARK qualifiers identify parts and variants. SKOS notations are lexical codes unique within a concept scheme and are not a substitute for URIs. Fragments and f-components identify constituents without changing the assigned name.", "source_refs": [ "SRC-026", "SRC-029", "SRC-032", "SRC-011", "SRC-001" ], "questions": [ { "id": "granularity-qualifiers-and-notations-q01", "text": "At what granularity is the identifier defined, and may finer parts be addressed by qualifiers or fragments rather than new assignments?", "kind": "composition", "answer_data": [ "granularityLevel", "qualifierSyntax", "fragmentSemantics" ] }, { "id": "granularity-qualifiers-and-notations-q02", "text": "If a notation or code is used, is it unique only within a concept scheme, and what URI or URN is the preferred computational identifier?", "kind": "interoperability", "answer_data": [ "notationValue", "conceptSchemeRef", "preferredUri" ] }, { "id": "granularity-qualifiers-and-notations-q03", "text": "Do content-negotiated, language, format or version variants share the assigned name or require distinct identifiers?", "kind": "classification", "answer_data": [ "variantPolicy", "contentNegotiationFlag", "versionedIdPolicy" ] } ], "data_elements": [ { "id": "granularity-qualifiers-and-notations-data01", "name": "Granularity level", "description": "Stated grain of the identified object.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-026", "SRC-029" ] }, { "id": "granularity-qualifiers-and-notations-data02", "name": "Qualifier syntax", "description": "Rules for parts, variants or fragments.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-032", "SRC-001" ] }, { "id": "granularity-qualifiers-and-notations-data03", "name": "Notation", "description": "Lexical code unique within a scheme, if any.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Granularity and qualifier rules are constraints of the scheme definition and assignment record; they are expressed inline unless the scheme publishes a separate qualifier profile." } ] }, { "id": "identifier-state-model", "name": "Identifier State Model", "description": "The state vocabulary an identifier moves through and the transitions the scheme permits.", "source_refs": [ "SRC-014", "SRC-005", "SRC-003", "SRC-012" ], "findings": [ { "id": "identifier-lifecycle-states", "name": "State vocabulary, transitions and consumer duties", "description": "Identifiers are not simply present or absent. The LEI system publishes an explicit registration status vocabulary covering issued, lapsed, merged, retired, annulled, duplicate and transfer states, tied to a renewal obligation. The IANA language subtag registry carries deprecation as a dated field with an optional preferred-value pointing at a successor, while never removing the record. RFC 8126 separates unassigned from reserved. DID methods must define a deactivate operation. A consuming agent needs to know not only the current state but what it is now obliged to do.", "source_refs": [ "SRC-014", "SRC-005", "SRC-003", "SRC-012" ], "questions": [ { "id": "q-state-vocabulary", "text": "What is the complete state vocabulary for an identifier under this scheme?", "kind": "state", "answer_data": [ "Enumerated state values with definitions", "Which states are terminal", "Default state on first assignment" ] }, { "id": "q-state-transitions", "text": "Which state transitions are permitted, and who may trigger each one?", "kind": "lifecycle", "answer_data": [ "Permitted transition pairs", "Triggering role for each", "Evidence required for each transition" ] }, { "id": "q-consumer-duty-on-deprecation", "text": "What must a consumer do when an identifier it holds becomes deprecated or retired?", "kind": "requirement", "answer_data": [ "Required consumer action", "Successor identifier where one exists", "Grace period before references are treated as stale" ] }, { "id": "q-renewal-obligation", "text": "Does the scheme impose a renewal or revalidation duty, and what happens if it lapses?", "kind": "requirement", "answer_data": [ "Renewal interval", "Lapse state and its effects", "Reinstatement procedure" ] }, { "id": "q-state-observation", "text": "How does a consumer determine the current state of an identifier, and how fresh is that answer?", "kind": "access", "answer_data": [ "State query interface", "Publication latency", "Observation timestamp returned with the state" ] } ], "data_elements": [ { "id": "de-identifier-state", "name": "Identifier state", "description": "Current coded state of an identifier under the scheme's state vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-003" ] }, { "id": "de-state-changed-at", "name": "State change time", "description": "Time at which the identifier entered its current state.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-005" ] }, { "id": "de-state-observed-at", "name": "State observation time", "description": "Time at which the state was observed or retrieved by the recording party.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-successor-identifier", "name": "Successor identifier", "description": "Preferred replacement identifier where the current one is deprecated or superseded.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-015" ] }, { "id": "de-renewal-due-at", "name": "Renewal due time", "description": "Time by which the assignment must be revalidated to avoid lapsing.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "identifier-state-event-log", "name": "Identifier state event log", "description": "Append-only log of state transitions for identifiers under the scheme, each entry carrying prior state, new state, trigger, actor, effective time and record time.", "media_or_form": [ "append-only event log", "structured record stream" ], "serial": true, "identity_strategy": "Canonical identifier value plus monotonically increasing sequence number; each entry additionally stamped with an RFC 3339 effective and record time.", "source_refs": [ "SRC-014", "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "reuse-succession-and-continuity", "name": "Reuse, Succession and Referent Change", "description": "Whether a retired identifier may be bound again, and how splits, merges and transfers of the referent are expressed.", "source_refs": [ "SRC-022", "SRC-001", "SRC-005", "SRC-015" ], "findings": [ { "id": "reuse-and-reassignment-policy", "name": "Reuse policy, quarantine and supersession", "description": "Non-reuse is a policy choice, not a law of naming, and this is where naive models fail. RFC 8141 asks formal-namespace registrants to demonstrate a commitment not to reassign, and BCP 47 guarantees that subtags are never removed or reassigned. GS1 by contrast operated timed reuse until an all-sector non-reallocation rule took effect after December 2018, and it still permits reuse twelve months after catalogue deletion for items that were never produced, while withdrawn-and-reintroduced items keep their original identifier. Supersession, splits and merges need explicit relation vocabulary of the kind DataCite provides.", "source_refs": [ "SRC-022", "SRC-001", "SRC-005", "SRC-015", "SRC-014" ], "questions": [ { "id": "q-reuse-permitted", "text": "Does this scheme permit a retired identifier to be bound to a different referent?", "kind": "constraint", "answer_data": [ "Reuse permission statement with its clause", "Effective date of the current rule", "Prior rule and whether values assigned under it are grandfathered" ] }, { "id": "q-reuse-quarantine", "text": "If reuse is permitted, what quarantine period and preconditions apply?", "kind": "constraint", "answer_data": [ "Quarantine duration", "Preconditions such as catalogue deletion or never-produced status", "Party that verifies the preconditions" ] }, { "id": "q-referent-transfer", "text": "When custody of the referent transfers, does the identifier travel with it?", "kind": "ownership", "answer_data": [ "Transfer rule", "Record of the prior and new registrant", "Effect on resolution targets" ] }, { "id": "q-split-merge", "text": "How are splits and merges of the referent expressed in identifier terms?", "kind": "relationship", "answer_data": [ "Relation vocabulary used", "Whether a new identifier is minted for each part", "Retention rule for the superseded identifier" ] }, { "id": "q-reuse-detection", "text": "How can a consumer detect that an identifier it holds now denotes a different referent?", "kind": "quality", "answer_data": [ "Detection signal available to consumers", "Historical binding record availability", "Recommended re-verification interval" ] } ], "data_elements": [ { "id": "de-reuse-permitted-flag", "name": "Reuse permitted flag", "description": "Whether the scheme permits reassignment of a retired identifier.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-022", "SRC-001" ] }, { "id": "de-quarantine-duration", "name": "Quarantine duration", "description": "Period a retired identifier must remain unassigned before any permitted reuse.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "de-reuse-exception", "name": "Reuse exception clause", "description": "A stated exception to the scheme's general reuse rule, with its preconditions.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "de-supersession-relation", "name": "Supersession relation", "description": "Typed relation between a superseded identifier and its successor or parts.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-prior-binding-record", "name": "Prior binding record", "description": "Historical binding of the identifier to an earlier referent, retained after retirement.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-014" ] } ], "artifacts": [ { "id": "reuse-policy-statement", "name": "Reuse and reassignment policy statement", "description": "Published statement of whether reuse is permitted, the quarantine period, every exception and the effective date of each rule version.", "media_or_form": [ "published statement", "specification clause" ], "serial": true, "identity_strategy": "Scheme registry key plus policy version; each version carries an RFC 3339 effective timestamp and supersedes the prior version explicitly.", "source_refs": [ "SRC-022", "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "split-merge-and-alias-continuity", "name": "Split, merge and aliasing", "description": "Public identities and bibliographic identifiers are sometimes merged or split. SKOS exactMatch is transitive and maps concepts across schemes without asserting owl:sameAs. A resource may carry several URNs for similar or different purposes, which is aliasing rather than merge.", "source_refs": [ "SRC-001", "SRC-011", "SRC-026" ], "questions": [ { "id": "split-merge-and-alias-continuity-q01", "text": "If two identifiers were merged, which value survives, which are aliases, and is the merge reversible?", "kind": "relationship", "answer_data": [ "survivingId", "deprecatedIds", "reversibleFlag" ] }, { "id": "split-merge-and-alias-continuity-q02", "text": "If one identifier was split, which new identifiers were minted for which new referents, and what is the parent identifier?", "kind": "event", "answer_data": [ "parentId", "childIds", "splitEventTime" ] }, { "id": "split-merge-and-alias-continuity-q03", "text": "Are multiple identifiers for one referent true aliases, purpose-specific identifiers, or embeddings of another scheme?", "kind": "classification", "answer_data": [ "aliasType", "purposeCode", "embeddedSchemeRef" ] } ], "data_elements": [ { "id": "split-merge-and-alias-continuity-data01", "name": "Surviving identifier", "description": "Canonical identifier after merge.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "split-merge-and-alias-continuity-data02", "name": "Alias set", "description": "Other identifiers treated as aliases.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "split-merge-and-alias-continuity-data03", "name": "Match quality", "description": "exact, close, related or unspecified.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "split-merge-and-alias-continuity-artifact01", "name": "Merge or split record", "description": "Authoritative event that rewired identifier-to-referent bindings.", "media_or_form": [ "registry merge notice", "SKOS mapping file" ], "serial": true, "identity_strategy": "Event identifier from the issuing registry; do not reuse either identifier value as the event id.", "source_refs": [ "SRC-011", "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "namespace-capacity", "name": "Namespace Capacity and Exhaustion", "description": "How many identifiers the scheme can still issue, how fast it is consuming them, and what happens when it runs out.", "source_refs": [ "SRC-006", "SRC-019", "SRC-007", "SRC-003" ], "findings": [ { "id": "capacity-and-exhaustion-planning", "name": "Capacity, consumption rate and extension strategy", "description": "Namespace exhaustion is a foreseeable failure with long lead times and is routinely omitted from scheme documentation. RFC 9562 makes the point in the probabilistic case: implementers must weigh the consequences of collision and choose between local and global uniqueness guarantees. ARK addresses the combinatorial case directly by recommending digit-heavy names with sparing use of a restricted alphabet to raise namespace density. Hierarchical schemes shift the problem to the delegation tree, where a parent can extend capacity by widening or deepening arcs.", "source_refs": [ "SRC-006", "SRC-019", "SRC-007", "SRC-003" ], "questions": [ { "id": "q-capacity-total", "text": "What is the theoretical capacity of this namespace under its current grammar?", "kind": "measurement", "answer_data": [ "Capacity figure with the calculation basis", "Constraining component of the grammar", "Any capacity already withheld as reserved" ] }, { "id": "q-consumption-rate", "text": "What is the observed allocation rate, and what is the projected exhaustion date?", "kind": "measurement", "answer_data": [ "Allocation rate with its measurement window", "Projected exhaustion date", "Confidence interval or sensitivity of the projection" ] }, { "id": "q-extension-strategy", "text": "How can capacity be extended without invalidating existing identifiers?", "kind": "decision", "answer_data": [ "Extension mechanism such as longer values, new arcs or a new prefix range", "Backward-compatibility impact", "Lead time required" ] }, { "id": "q-collision-tolerance", "text": "For probabilistically generated identifiers, what collision probability is accepted and on what basis?", "kind": "constraint", "answer_data": [ "Accepted collision probability", "Consequence analysis for a collision", "Detection and remediation procedure" ] } ], "data_elements": [ { "id": "de-namespace-capacity", "name": "Namespace capacity", "description": "Total number of distinct identifiers the grammar admits.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-006" ] }, { "id": "de-allocation-rate", "name": "Allocation rate", "description": "Observed identifiers allocated per unit time over a stated window.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-projected-exhaustion", "name": "Projected exhaustion date", "description": "Date at which capacity is projected to be consumed.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "de-collision-tolerance", "name": "Accepted collision probability", "description": "Collision probability the scheme operator accepts for generated identifiers.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "capacity-forecast-report", "name": "Capacity and exhaustion forecast report", "description": "Periodic report of capacity, consumption, projected exhaustion and the extension options with their lead times.", "media_or_form": [ "structured report", "tabular dataset" ], "serial": true, "identity_strategy": "Scheme registry key plus reporting period; serial number assigned in issue order with an RFC 3339 issue timestamp.", "source_refs": [ "SRC-019", "SRC-006", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "resolution-and-persistence", "name": "Resolution, Dereference and Persistence", "description": "Whether the scheme resolves at all, through which services, what a resolution returns, and what is actually being promised about the future.", "rationale": "RFC 8141 requires every namespace registration to state whether resolution is intended; RFC 3986 insists that identification does not imply access; the Handle System shows a two-tier resolution architecture that keeps identifier separate from location; ARK states plainly that persistence is a matter of service rather than of naming syntax. Resolution and persistence are therefore declared properties of the scheme, distinct from its grammar and its assignment register.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-019" ], "layers": [ { "id": "resolution-service", "name": "Resolution Service", "description": "The services that dereference identifiers of this scheme, their protocols, coverage and operators.", "source_refs": [ "SRC-007", "SRC-001", "SRC-012", "SRC-021" ], "findings": [ { "id": "resolver-endpoint-and-protocol", "name": "Resolver endpoints, protocols and coverage", "description": "The Handle System illustrates the general architecture: a global registry maps a naming authority to the local service responsible for it, clients cache that mapping, and resolution requests proceed without authentication unless confidential values are involved. RFC 8141 reserves a resolution parameter component but forbids its use before semantics are standardised, and requires a resolution statement in the registration. DID methods must each define a resolve operation. Coverage matters as much as the endpoint: a resolver that covers only part of a namespace produces silent failures indistinguishable from non-existence.", "source_refs": [ "SRC-007", "SRC-001", "SRC-012", "SRC-021" ], "questions": [ { "id": "q-resolution-intended", "text": "Is resolution intended for this scheme at all, and what did the registration state?", "kind": "definition", "answer_data": [ "Resolution intent statement as filed", "Whether resolution is mandatory or optional for registrants", "Clause reference" ] }, { "id": "q-resolver-endpoints", "text": "Which services resolve identifiers of this scheme, over which protocols?", "kind": "process", "answer_data": [ "Endpoint references", "Protocols supported", "Operator of each endpoint" ] }, { "id": "q-resolver-coverage", "text": "What portion of the namespace does each resolver actually cover?", "kind": "quality", "answer_data": [ "Coverage expressed as namespace portions", "Known gaps", "Behaviour on an out-of-coverage request" ] }, { "id": "q-resolution-parameters", "text": "Are resolution parameters or service requests supported, and with what standardised semantics?", "kind": "interoperability", "answer_data": [ "Supported parameter forms", "Standardisation status of their semantics", "Whether clients should pass fragment-like components to the resolver" ] }, { "id": "q-resolution-terms", "text": "What service level, caching guidance and rate limits govern resolution at volume?", "kind": "constraint", "answer_data": [ "Service level terms", "Caching guidance", "Rate limits and bulk access route" ] } ], "data_elements": [ { "id": "de-resolution-intended", "name": "Resolution intent", "description": "Whether the scheme intends its identifiers to be resolvable.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-resolver-endpoint", "name": "Resolver endpoint reference", "description": "Reference to a service that dereferences identifiers of the scheme.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "de-resolution-protocol", "name": "Resolution protocol", "description": "Protocol by which a resolver is queried.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-resolver-coverage", "name": "Resolver coverage statement", "description": "Portion of the namespace a given resolver serves.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-resolution-service-level", "name": "Resolution service level", "description": "Availability, latency and rate-limit terms for resolution.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-021" ] } ], "artifacts": [ { "id": "resolver-service-descriptor", "name": "Resolver service descriptor", "description": "Descriptor of each resolution service with endpoint, protocol, coverage, operator and service level.", "media_or_form": [ "service descriptor record", "published catalogue entry" ], "serial": false, "identity_strategy": "Scheme registry key plus resolver endpoint reference; where the resolver has its own registered identifier, that identifier takes priority.", "source_refs": [ "SRC-007", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "identification-versus-dereference", "name": "Identification distinguished from dereference", "description": "RFC 3986 states that a URI provides identification only and that access to the resource is neither guaranteed nor implied, and it discourages the strict name-versus-locator partition on which many identifier arguments rest. XML namespace names are explicitly not intended for retrieval. Yet FAIR expects data to be retrievable by identifier over a standardised protocol, and users routinely treat a failed resolution as evidence that the referent does not exist. This finding fixes the interpretation a consuming agent must apply so that resolution failure is not mistaken for non-existence, nor successful resolution for authenticity of the referent.", "source_refs": [ "SRC-002", "SRC-010", "SRC-009", "SRC-016", "SRC-019" ], "questions": [ { "id": "q-access-guarantee", "text": "Does holding a well-formed identifier of this scheme guarantee any access to the referent?", "kind": "constraint", "answer_data": [ "Explicit access guarantee or disclaimer", "Clause reference", "Cases where resolution exists but access is restricted" ] }, { "id": "q-failed-resolution-meaning", "text": "What may a consumer conclude when resolution fails?", "kind": "exception", "answer_data": [ "Enumerated failure causes", "Which causes imply non-existence and which do not", "Recommended fallback for each" ] }, { "id": "q-namespace-dereference", "text": "Is the scheme's own namespace expression intended to be dereferenceable?", "kind": "interoperability", "answer_data": [ "Dereference intent for the namespace token", "What is returned if it is dereferenced", "Whether dereference is required for correct interpretation" ] }, { "id": "q-resolution-authenticity", "text": "Does successful resolution establish that the returned resource is the intended referent?", "kind": "evidence", "answer_data": [ "Authenticity guarantee or disclaimer", "Verification mechanism where one exists", "Attack scenarios the resolver does not defend against" ] } ], "data_elements": [ { "id": "de-access-guarantee", "name": "Access guarantee statement", "description": "Declared relationship between holding an identifier and obtaining access to the referent.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-016" ] }, { "id": "de-failure-semantics", "name": "Resolution failure semantics", "description": "Interpretation rule for each resolution failure mode.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-019" ] }, { "id": "de-namespace-dereferenceable", "name": "Namespace dereferenceability flag", "description": "Whether the namespace token is intended to be retrievable.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "This finding records an interpretive constraint that is already required to be declared inside the scheme registration record under RFC 8141 section 6.4.6 and is asserted by the URI specification itself; creating a separate deliverable would duplicate the registration artifact and invite the two to drift. It is therefore carried as inline declared properties on the scheme record and enforced through the failure-semantics rule set." }, { "id": "scheme-specific-resolution-parameters", "name": "Resolution parameters and DID URL options", "description": "RFC 8141 r-components are reserved for passing parameters to resolution services and must not affect assigned-name equivalence. DID parameters service, relativeRef, versionId, versionTime and hl distinguish which resource is identified versus how resolution is performed.", "source_refs": [ "SRC-001", "SRC-025" ], "questions": [ { "id": "scheme-specific-resolution-parameters-q01", "text": "Does this scheme define r-component or equivalent resolver parameters, or are they still undefined and therefore not to be used?", "kind": "constraint", "answer_data": [ "rComponentDefined", "parameterRegistryRef" ] }, { "id": "scheme-specific-resolution-parameters-q02", "text": "Which DID URL parameters are supported to select service, relative resource, version or hash integrity?", "kind": "interoperability", "answer_data": [ "supportedDidParameters", "hashlinkSupport" ] }, { "id": "scheme-specific-resolution-parameters-q03", "text": "Which inputs must be part of the identifier URL and which must be resolver options that are not part of identity?", "kind": "decision", "answer_data": [ "identityParameters", "resolverOptions" ] } ], "data_elements": [ { "id": "scheme-specific-resolution-parameters-data01", "name": "Resolver parameter profile", "description": "Defined r-component or DID parameter semantics.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-025" ] }, { "id": "scheme-specific-resolution-parameters-data02", "name": "Parameters that affect identity", "description": "Which query parameters are part of the resource identity.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-025" ] } ], "artifacts": [], "inline_only_rationale": "Resolver parameter profiles are reference data on the scheme and resolver; they become artefacts only when published as a separate parameter registry." } ] }, { "id": "persistence-commitment", "name": "Persistence Commitment", "description": "Who promises what, for how long, and what survives when the referent does not.", "source_refs": [ "SRC-019", "SRC-016", "SRC-009", "SRC-021" ], "findings": [ { "id": "persistence-policy-and-commitment-statement", "name": "Persistence commitment, horizon and tombstone behaviour", "description": "ARK is unusually explicit that persistence is purely a matter of service and that only a current provider can say what commitment it intends; its policy service returns declarations addressing object availability, identifier validity, content invariance and change history. FAIR asks separately that metadata remain accessible even when the data are not. W3C web architecture asks owners to provide representations consistently and predictably. Together these give four separable promises that are routinely bundled into the single unfalsifiable word persistent.", "source_refs": [ "SRC-019", "SRC-016", "SRC-009", "SRC-021" ], "questions": [ { "id": "q-commitment-parties", "text": "Who makes the persistence commitment for a given identifier, and are they the current provider?", "kind": "ownership", "answer_data": [ "Committing party reference", "Whether that party currently controls resolution", "Date the commitment was made" ] }, { "id": "q-commitment-content", "text": "Which of identifier validity, object availability, content invariance and change history are actually promised?", "kind": "requirement", "answer_data": [ "Promise held per dimension", "Exclusions and caveats", "Wording of the published declaration" ] }, { "id": "q-commitment-horizon", "text": "Over what horizon does the commitment run, and what backs it?", "kind": "temporal", "answer_data": [ "Stated horizon", "Funding or legal backing", "Review interval for the commitment" ] }, { "id": "q-tombstone", "text": "What is returned once the referent is withdrawn, and is its metadata retained?", "kind": "exception", "answer_data": [ "Tombstone behaviour", "Metadata retained after withdrawal", "Whether the identifier remains resolvable" ] }, { "id": "q-custody-transfer", "text": "How is the commitment transferred if custody of the referent or the resolver changes?", "kind": "process", "answer_data": [ "Transfer procedure", "Notification obligations", "Evidence of prior transfers" ] } ], "data_elements": [ { "id": "de-commitment-party", "name": "Committing party", "description": "Party issuing the persistence commitment.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "de-commitment-dimension", "name": "Commitment dimension", "description": "A specific promise dimension such as identifier validity, object availability, content invariance or change history, with its declared level.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "de-commitment-horizon", "name": "Commitment horizon", "description": "Period over which the commitment is asserted to hold.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "de-tombstone-policy", "name": "Tombstone policy", "description": "What is served and what metadata is retained after the referent is withdrawn.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-019" ] } ], "artifacts": [ { "id": "persistence-commitment-statement", "name": "Persistence commitment statement", "description": "Published declaration by the current provider stating, per dimension, what is promised, for how long, with what exclusions and what happens on withdrawal or custody transfer.", "media_or_form": [ "published declaration", "structured record" ], "serial": true, "identity_strategy": "Committing party reference plus namespace portion plus RFC 3339 issue timestamp; successive statements are serially numbered and supersede explicitly.", "source_refs": [ "SRC-019", "SRC-016" ] } ], "inline_only_rationale": null } ] }, { "id": "resolution-response-and-metadata", "name": "Resolution Response and Metadata", "description": "What a resolution returns, how metadata is requested, and how the outcome is recorded.", "source_refs": [ "SRC-007", "SRC-019", "SRC-012", "SRC-015" ], "findings": [ { "id": "resolution-outcome-record", "name": "Resolution outcome, returned values and audit trail", "description": "A handle carries multiple typed and indexed values, each with its own administrative controls, so resolution returns a value set rather than a single location. ARK reserves an inflection that returns descriptive metadata together with the commitment statement. DID resolution returns a document plus resolution metadata. For an operating agent the outcome must be recorded with the identifier as supplied, the identifier as canonicalized, the resolver consulted, the observation time and the outcome class, because the same identifier resolved at two times is two facts.", "source_refs": [ "SRC-007", "SRC-019", "SRC-012", "SRC-015" ], "questions": [ { "id": "q-resolution-return", "text": "What does a successful resolution return, and is it a single value or a typed set?", "kind": "definition", "answer_data": [ "Structure of the returned value set", "Types and indexes present", "Which value is the default target" ] }, { "id": "q-metadata-request", "text": "How does a client request descriptive metadata or a policy statement rather than the referent?", "kind": "process", "answer_data": [ "Request mechanism such as an inflection, parameter or content negotiation", "Metadata profile returned", "Whether support is mandatory or optional" ] }, { "id": "q-outcome-classes", "text": "What outcome classes must a client distinguish, and how are they signalled?", "kind": "exception", "answer_data": [ "Outcome class vocabulary including success, gone, withdrawn, not-covered and unavailable", "Signalling mechanism per class", "Retry guidance" ] }, { "id": "q-resolution-audit", "text": "What must be recorded about a resolution so that the result can be reproduced or disputed later?", "kind": "provenance", "answer_data": [ "Fields recorded per resolution attempt", "Observation timestamp in RFC 3339", "Retention period for the record" ] } ], "data_elements": [ { "id": "de-resolution-outcome", "name": "Resolution outcome class", "description": "Coded outcome of a resolution attempt.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "de-resolution-observed-at", "name": "Resolution observation time", "description": "Time at which the resolution attempt was made.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-resolved-value", "name": "Resolved value entry", "description": "A typed, indexed value returned by resolution.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-resolution-metadata", "name": "Resolution metadata", "description": "Metadata about the resolution process itself, distinct from metadata about the referent.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-resolver-consulted", "name": "Resolver consulted", "description": "Reference to the resolver that produced the outcome.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "resolution-audit-log", "name": "Resolution audit log", "description": "Append-only log of resolution attempts recording supplied and canonical identifier, resolver consulted, outcome class, returned value summary and observation time.", "media_or_form": [ "append-only event log", "structured record stream" ], "serial": true, "identity_strategy": "Monotonic sequence number within the log, each entry stamped with an RFC 3339 observation time and the canonical identifier value.", "source_refs": [ "SRC-007", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "access-controlled-and-failing-resolution", "name": "Access-controlled and failing resolution", "description": "RFC 8141 contemplates authorised retrieval of representations while others receive only metadata, as in a national legal-deposit collection. Resolution may also be undefined for namespaces that identify protocol features rather than retrievable resources. Failure modes and caching must not equate non-retrieval with non-identity.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "questions": [ { "id": "access-controlled-and-failing-resolution-q01", "text": "Who may obtain a representation versus metadata versus a mere existence check, and under which exception process?", "kind": "access", "answer_data": [ "representationAudience", "metadataAudience", "exceptionProcess" ] }, { "id": "access-controlled-and-failing-resolution-q02", "text": "If the scheme is not intended as a locator, what does software that obtains the identifier do instead of retrieval?", "kind": "exception", "answer_data": [ "nonLocatorBehaviour", "protocolSlotGuidance" ] }, { "id": "access-controlled-and-failing-resolution-q03", "text": "How are not-found, gone, unauthorised and resolver-unavailable distinguished in logs without treating them as identifier invalidity?", "kind": "exception", "answer_data": [ "failureCodes", "cachePolicy", "invalidVersusUnresolved" ] } ], "data_elements": [ { "id": "access-controlled-and-failing-resolution-data01", "name": "Resolution access policy", "description": "Who may retrieve which result class.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "access-controlled-and-failing-resolution-data02", "name": "Non-locator scheme flag", "description": "True when default retrieval is not defined.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [ { "id": "access-controlled-and-failing-resolution-artifact01", "name": "Resolution audit log", "description": "Auditable record of resolution requests where policy requires it, especially bulk or authorised access.", "media_or_form": [ "audit log" ], "serial": true, "identity_strategy": "Log event identifiers are ULIDs or equivalent; include event time and ingestion time separately.", "source_refs": [ "SRC-004", "SRC-001" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "interoperability-and-mapping", "name": "Interoperability, Carriage and Conflict", "description": "How identifiers of this scheme relate to identifiers of other schemes, how they travel inside other models, and how collisions and drift are detected.", "rationale": "SKOS provides the only widely adopted mapping vocabulary with an explicit warning about compounding error across chained mappings; FHIR shows the carriage shape that keeps a value interpretable outside its home system; W3C web architecture names URI collision and aliasing as first-order harms; BCP 47 demonstrates how a registry absorbs change in an upstream source standard without breaking existing references. Mapping, carriage and conflict are distinct from allocation and resolution.", "source_refs": [ "SRC-011", "SRC-013", "SRC-009", "SRC-005" ], "layers": [ { "id": "crosswalks-and-mappings", "name": "Crosswalks and Mapping Assertions", "description": "Declared correspondences between identifiers or schemes, with relation type, evidence and quality.", "source_refs": [ "SRC-011", "SRC-015", "SRC-013", "SRC-023" ], "findings": [ { "id": "cross-scheme-mapping-assertion", "name": "Mapping assertion: relation type, evidence, quality and chaining", "description": "A crosswalk is an assertion by a party, not a fact of the world. SKOS distinguishes exact, close, broad, narrow and related matches, declares exactMatch transitive and symmetric while deliberately withholding transitivity from closeMatch so that errors do not compound when mappings are chained across schemes, and makes exactMatch disjoint from broadMatch and relatedMatch. DataCite supplies a complementary vocabulary for identity and version relations between registered resources. Every assertion needs an asserter, evidence, a quality judgement and a retirement path.", "source_refs": [ "SRC-011", "SRC-015", "SRC-013", "SRC-023" ], "questions": [ { "id": "q-mapping-relation-type", "text": "What relation type does this mapping assert, and is it symmetric or transitive?", "kind": "relationship", "answer_data": [ "Relation type from a named vocabulary", "Symmetry and transitivity properties", "Disjointness constraints with other relations" ] }, { "id": "q-mapping-asserter", "text": "Who asserted this mapping, on what evidence, and when?", "kind": "provenance", "answer_data": [ "Asserting party reference", "Evidence basis such as authority publication, expert review or algorithmic match", "Assertion time in RFC 3339" ] }, { "id": "q-mapping-quality", "text": "What is the quality of this mapping and how was it measured?", "kind": "measurement", "answer_data": [ "Quality grade or score", "Measurement method and sample", "Known systematic errors" ] }, { "id": "q-mapping-chaining", "text": "May this mapping be chained with others to infer a further correspondence?", "kind": "constraint", "answer_data": [ "Chaining permission with maximum depth", "Relation types that must not be chained", "Error accumulation estimate" ] }, { "id": "q-mapping-retirement", "text": "How is a mapping withdrawn when one side is deprecated or reassigned?", "kind": "lifecycle", "answer_data": [ "Withdrawal trigger and procedure", "Whether withdrawn mappings are retained for history", "Notification path to consumers" ] }, { "id": "q-mapping-cardinality", "text": "What cardinality does the mapping have, and how are one-to-many correspondences represented?", "kind": "composition", "answer_data": [ "Cardinality of the correspondence", "Representation of splits and merges", "Rule for selecting a preferred counterpart" ] } ], "data_elements": [ { "id": "de-mapping-source", "name": "Mapping source identifier", "description": "The identifier on the asserting side of the correspondence, with its namespace.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-015" ] }, { "id": "de-mapping-target", "name": "Mapping target identifier", "description": "The identifier on the counterpart side of the correspondence, with its namespace.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-015" ] }, { "id": "de-mapping-relation", "name": "Mapping relation type", "description": "Coded relation asserted between source and target.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-015" ] }, { "id": "de-mapping-asserter", "name": "Mapping asserter", "description": "Party asserting the correspondence.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "de-mapping-quality", "name": "Mapping quality grade", "description": "Assessed quality of the correspondence with its method.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-mapping-asserted-at", "name": "Mapping assertion time", "description": "Time the correspondence was asserted.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-015" ] }, { "id": "de-mapping-chainable", "name": "Chaining permitted flag", "description": "Whether the mapping may participate in transitive inference.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "crosswalk-mapping-set", "name": "Crosswalk mapping set", "description": "A published set of mapping assertions between two schemes, each carrying relation type, asserter, evidence, quality and assertion time.", "media_or_form": [ "tabular dataset", "structured record set" ], "serial": true, "identity_strategy": "Source scheme key plus target scheme key plus mapping-set version; each release stamped with an RFC 3339 issue timestamp.", "source_refs": [ "SRC-011", "SRC-015" ] } ], "inline_only_rationale": null } ] }, { "id": "carriage-and-embedding", "name": "Carriage and Embedding in Consuming Models", "description": "How an identifier travels inside another model so that it stays interpretable, comparable and attributable.", "source_refs": [ "SRC-013", "SRC-010", "SRC-001", "SRC-023" ], "findings": [ { "id": "identifier-carriage-profile", "name": "Carriage profile: system plus value, use, assigner and period", "description": "This is the mixin surface. FHIR's Identifier shows the minimum that must travel with a value for it to remain interpretable: a system establishing the namespace, the value unique within it, a coded type, a use marker that modifies meaning, a validity period and an assigner. XML Namespaces warns that a prefix functions only as a local placeholder and that applications should use the namespace name, not the prefix, whenever a name's scope extends beyond its document. ISO 6523 code designators show the same job done with a numeric scheme code instead of a URI. A consuming model that stores a bare string has thrown away the interpretation.", "source_refs": [ "SRC-013", "SRC-010", "SRC-023", "SRC-001", "SRC-009" ], "questions": [ { "id": "q-carriage-shape", "text": "What must accompany an identifier value for a consumer to interpret it without external context?", "kind": "interoperability", "answer_data": [ "Required accompanying fields", "Canonical exchange representation", "Minimum viable subset where the full shape is unavailable" ] }, { "id": "q-carriage-prefix", "text": "Are abbreviations or prefixes permitted in carriage, and is their scope local only?", "kind": "constraint", "answer_data": [ "Prefix or abbreviation permission", "Scope limitation statement", "Expansion rule to the full namespace token" ] }, { "id": "q-carriage-multiplicity", "text": "When a referent holds several identifiers, how is the preferred one designated?", "kind": "classification", "answer_data": [ "Use markers available", "Preference selection rule", "Handling of old and secondary identifiers" ] }, { "id": "q-carriage-period", "text": "How is the period during which an identifier was valid for the referent recorded?", "kind": "temporal", "answer_data": [ "Period representation with RFC 3339 bounds", "Treatment of open-ended periods", "Interaction with the identifier state model" ] }, { "id": "q-carriage-attribution", "text": "How is the assigning body recorded alongside the value?", "kind": "provenance", "answer_data": [ "Assigner reference form", "Whether the assigner is derivable from the value structure", "Fallback when the assigner is unknown" ] } ], "data_elements": [ { "id": "de-carriage-system", "name": "Carried namespace token", "description": "Namespace expression accompanying a carried identifier value.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-023" ] }, { "id": "de-carriage-value", "name": "Carried identifier value", "description": "The identifier value as carried in a consuming model.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "de-carriage-type", "name": "Carried identifier type", "description": "Coded type of the identifier used to select the right one for a purpose.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-carriage-scheme-version", "name": "Carried scheme version", "description": "Version of the scheme in force when the value was captured, enabling drift detection.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-carriage-prefix-local", "name": "Local prefix alias", "description": "Document-local abbreviation for a namespace token, valid only within its containing document.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "carriage-profile-specification", "name": "Identifier carriage profile", "description": "Specification of how identifiers of this scheme are carried in consuming models, naming required fields, canonical exchange form, prefix rules and preference selection.", "media_or_form": [ "profile specification", "structured record" ], "serial": false, "identity_strategy": "Scheme registry key plus profile version; profiles never identified by date alone.", "source_refs": [ "SRC-013", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "embedding-and-encapsulation", "name": "Embedding and encapsulation", "description": "RFC 8141 allows NSS to encapsulate hierarchical names from non-URN systems. ISO 26324 describes integrating another scheme character string through DOI syntax or system metadata. FHIR says if the value is a full URI then system SHALL be urn:ietf:rfc:3986. Embedding is not the same as mapping.", "source_refs": [ "SRC-001", "SRC-026", "SRC-030" ], "questions": [ { "id": "embedding-and-encapsulation-q01", "text": "Does this identifier embed another scheme native string, and what canonicalisation is applied before embedding?", "kind": "composition", "answer_data": [ "embeddedSchemeRef", "nativeString", "canonicalisationBeforeEmbed" ] }, { "id": "embedding-and-encapsulation-q02", "text": "Can the native identifier be recovered losslessly from the encapsulating form, and which form is canonical for matching?", "kind": "interoperability", "answer_data": [ "losslessRoundTrip", "canonicalForMatching" ] }, { "id": "embedding-and-encapsulation-q03", "text": "Does the encapsulating scheme claim to replace the native scheme, contrary to ISO 26324 non-replacement rule?", "kind": "constraint", "answer_data": [ "replacementClaimFlag", "coexistencePolicy" ] } ], "data_elements": [ { "id": "embedding-and-encapsulation-data01", "name": "Embedded scheme", "description": "Native scheme whose string is encapsulated.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-001" ] }, { "id": "embedding-and-encapsulation-data02", "name": "Lossless round-trip", "description": "Whether native form is recoverable.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Embedding rules are constraints on syntax and assignment; they are recorded inline on the scheme unless a dedicated profile is published." }, { "id": "computational-identifier-tuple", "name": "Computational identifier tuple", "description": "FHIR Identifier shows the operational pattern every consuming model needs: system namespace URI, value unique in that system, optional type, use, period and assigner. Comparison requires knowing the system. Values are case-sensitive unless the system says otherwise.", "source_refs": [ "SRC-030", "SRC-027" ], "questions": [ { "id": "computational-identifier-tuple-q01", "text": "What absolute namespace URI is the system, and what value is unique within it?", "kind": "identity", "answer_data": [ "systemUri", "value" ] }, { "id": "computational-identifier-tuple-q02", "text": "Is a coded identifier type recorded for when the system is unknown, without treating type as a substitute for system?", "kind": "classification", "answer_data": [ "identifierType", "typeVsSystemNote" ] }, { "id": "computational-identifier-tuple-q03", "text": "What normalisation is allowed before matching, and is case-insensitive comparison actually safe for this system?", "kind": "validation", "answer_data": [ "normalisationSteps", "caseInsensitiveSafeFlag" ] } ], "data_elements": [ { "id": "computational-identifier-tuple-data01", "name": "System namespace URI", "description": "Absolute URI identifying the unique-value set.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-030" ] }, { "id": "computational-identifier-tuple-data02", "name": "Identifier type", "description": "General category when system is unknown.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030" ] }, { "id": "computational-identifier-tuple-data03", "name": "Value case-sensitive", "description": "Whether matching must treat case as significant.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-030" ] } ], "artifacts": [], "inline_only_rationale": "The system-plus-value tuple is inline reference data carried on every identifier instance; it is not a file type." } ] }, { "id": "collision-drift-and-conflict", "name": "Collision, Drift and Conflict", "description": "Detecting duplicate denotation, unauthorised use and silent divergence from the governing scheme.", "source_refs": [ "SRC-009", "SRC-004", "SRC-003", "SRC-005" ], "findings": [ { "id": "collision-and-drift-detection", "name": "Collision, squatting, aliasing and upstream drift", "description": "W3C web architecture names two failure modes directly: collision, where distinct resources share an identifier, and aliasing, where one resource acquires arbitrarily many. BCP 35 warns against squatting and requires a new scheme to show utility beyond what is already registered. RFC 8126 provides a marker for values known to be in use without registration. BCP 47 shows the hardest case: an upstream source standard withdraws or reassigns a code, and the registry must absorb the change through deprecation and preferred-value mappings rather than by removing the record. Carrying the scheme version alongside every stored value is what makes such drift detectable at all.", "source_refs": [ "SRC-009", "SRC-004", "SRC-003", "SRC-005", "SRC-014" ], "questions": [ { "id": "q-collision-definition", "text": "What counts as a collision under this scheme, and how is one detected?", "kind": "quality", "answer_data": [ "Collision definition", "Detection method and cadence", "Historical collision incidents" ] }, { "id": "q-duplicate-resolution", "text": "When two identifiers are found to denote the same referent, which survives and how is the other marked?", "kind": "decision", "answer_data": [ "Survivorship rule", "Marking applied to the superseded identifier", "Party empowered to decide" ] }, { "id": "q-unauthorised-use", "text": "How is use of unregistered or squatted values discovered and handled?", "kind": "exception", "answer_data": [ "Discovery mechanism", "Marker used for known unregistered use", "Regularisation or enforcement route" ] }, { "id": "q-upstream-drift", "text": "When an upstream source standard changes a code, how does the scheme absorb the change?", "kind": "process", "answer_data": [ "Absorption procedure", "Whether records are ever removed", "Deprecation and preferred-value mechanics" ] }, { "id": "q-drift-detection-signal", "text": "What signal lets a consumer detect that stored values no longer match the scheme in force?", "kind": "quality", "answer_data": [ "Stored scheme version and comparison rule", "Revalidation cadence", "Escalation path on mismatch" ] } ], "data_elements": [ { "id": "de-collision-incident", "name": "Collision incident record", "description": "A detected case of two referents sharing an identifier or one referent holding conflicting identifiers.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-unregistered-use-marker", "name": "Known unregistered use marker", "description": "Marker recording a value in use without a registration.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-upstream-change-record", "name": "Upstream change record", "description": "A withdrawal or reassignment in a source standard and the scheme's response to it.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-drift-status", "name": "Drift status", "description": "Whether stored values conform to the scheme version currently in force.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-004" ] } ], "artifacts": [ { "id": "collision-and-drift-report", "name": "Collision and drift report", "description": "Periodic report of detected collisions, aliases, unregistered use and divergence from the scheme version in force, with remediation status per item.", "media_or_form": [ "structured report", "tabular dataset" ], "serial": true, "identity_strategy": "Scheme registry key plus reporting period; serial number in issue order with an RFC 3339 issue timestamp.", "source_refs": [ "SRC-009", "SRC-003", "SRC-005" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "assurance-risk-and-compliance", "name": "Assurance, Privacy and Legal Continuity", "description": "Whether the scheme's claims can be checked, what risk its values carry, and what legal footing keeps it running.", "rationale": "RFC 8141 makes a security and privacy analysis a mandatory part of a namespace registration; GDPR makes an identification number a route to identifiability and reserves national identification numbers to Member State law; NIST separates a label from a credential; GLEIF runs an explicit data quality programme; ARK insists that only a current provider can make a commitment. Assurance, privacy and legal continuity are governance concerns that no syntax rule can supply.", "source_refs": [ "SRC-001", "SRC-018", "SRC-017", "SRC-014" ], "layers": [ { "id": "quality-and-conformance", "name": "Quality and Conformance Evidence", "description": "What is claimed, what evidence supports it, and how defects are measured and remedied.", "source_refs": [ "SRC-014", "SRC-001", "SRC-004", "SRC-015" ], "findings": [ { "id": "conformance-and-quality-evidence", "name": "Conformance claims, defect measurement and audit", "description": "External standards are alignments until evidence is produced. A conformance claim must name the standard, the edition and the specific clause, and point at the test or audit that supports it. GLEIF's data quality programme shows that a registry's assertions about its own contents are measurable and reportable rather than declaratory. Mandatory metadata properties give a concrete completeness measure. Where no evidence exists, the honest record is an alignment claim, not conformance.", "source_refs": [ "SRC-014", "SRC-001", "SRC-004", "SRC-015", "SRC-016" ], "questions": [ { "id": "q-conformance-claim", "text": "Which standard, edition and clause does this scheme claim conformance to, and what evidence supports the claim?", "kind": "evidence", "answer_data": [ "Standard, edition and clause", "Evidence type such as test report, audit or self-declaration", "Date and issuing party of the evidence" ] }, { "id": "q-defect-rate", "text": "What defect rate is observed in the assignment register, and how is it measured?", "kind": "measurement", "answer_data": [ "Defect classes and rates", "Measurement method and population", "Trend over the last measured periods" ] }, { "id": "q-audit-regime", "text": "Who audits the scheme's operation, how often, and what are the published findings?", "kind": "authority", "answer_data": [ "Auditing party", "Audit cadence and scope", "Most recent findings and their status" ] }, { "id": "q-remediation", "text": "What is the remediation path when a defect or non-conformance is found?", "kind": "process", "answer_data": [ "Remediation procedure and owner", "Target resolution times by severity", "Escalation route" ] }, { "id": "q-alignment-not-conformance", "text": "Which external standards are aligned with but not conformed to, and where do they diverge?", "kind": "interoperability", "answer_data": [ "Aligned standards list", "Divergence points per standard", "Reason each divergence is retained" ] } ], "data_elements": [ { "id": "de-conformance-claim", "name": "Conformance claim", "description": "A claim of conformance to a named standard clause with its supporting evidence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "de-alignment-claim", "name": "Alignment claim", "description": "A declared alignment with an external standard, short of conformance, with divergence notes.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "de-defect-rate", "name": "Defect rate measure", "description": "Measured rate of a defect class in the register over a stated population and window.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-audit-record-ref", "name": "Audit record reference", "description": "Reference to an audit of the scheme's operation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "conformance-evidence-dossier", "name": "Conformance and quality evidence dossier", "description": "Collected conformance claims, alignment statements with divergences, defect measurements and audit findings for the scheme.", "media_or_form": [ "evidence dossier", "structured report" ], "serial": true, "identity_strategy": "Scheme registry key plus dossier edition; each edition carries an RFC 3339 issue timestamp and lists the claims it supersedes.", "source_refs": [ "SRC-014", "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "privacy-and-disclosure-risk", "name": "Privacy and Disclosure Risk", "description": "Whether identifier values are personal data, what they leak, and what they must never be used for.", "source_refs": [ "SRC-018", "SRC-001", "SRC-017", "SRC-006" ], "findings": [ { "id": "identifier-privacy-classification", "name": "Personal-data classification, leakage and misuse as a credential", "description": "GDPR Article 4(1) makes an identification number or online identifier a route to identifiability, Recital 26 keeps re-identifiable pseudonymised data within scope, Recital 30 names device and cookie identifiers explicitly, and Article 87 leaves national identification numbers to Member State law. RFC 8141 requires a filed analysis of comparison issues, information leakage and privacy. Time-based generated identifiers can disclose creation time and generator state. NIST separates a label from a credential: an identifier is never proof of anything, and treating it as an authenticator is a design fault, not a policy preference.", "source_refs": [ "SRC-018", "SRC-001", "SRC-017", "SRC-006" ], "questions": [ { "id": "q-personal-data-status", "text": "Are values of this scheme personal data, directly or through re-identification?", "kind": "classification", "answer_data": [ "Personal-data classification with reasoning", "Re-identification pathway if any", "Applicable legal regime and territory" ] }, { "id": "q-value-leakage", "text": "What does a value disclose about its referent or its creation to a party holding only the string?", "kind": "access", "answer_data": [ "Disclosed attributes", "Whether disclosure is intended", "Mitigations available" ] }, { "id": "q-enumeration-risk", "text": "Can the namespace be enumerated or harvested, and what controls limit that?", "kind": "access", "answer_data": [ "Enumerability assessment", "Rate limiting and bulk access controls", "Monitoring for harvesting" ] }, { "id": "q-credential-misuse", "text": "Is the value ever accepted as evidence of authorisation or identity, and how is that prevented?", "kind": "constraint", "answer_data": [ "Explicit prohibition statement", "Known systems that misuse it as a secret", "Compensating authentication requirement" ] }, { "id": "q-erasure-vs-persistence", "text": "How is an erasure or restriction request reconciled with a persistence commitment?", "kind": "exception", "answer_data": [ "Reconciliation procedure", "What is redacted versus what is retained", "Decision record and its approver" ] }, { "id": "q-national-number-restriction", "text": "Does any national or sectoral restriction limit processing of this identifier?", "kind": "authority", "answer_data": [ "Restricting instrument and territory", "Permitted purposes", "Consequence of breach" ] } ], "data_elements": [ { "id": "de-personal-data-class", "name": "Personal-data classification", "description": "Whether identifier values constitute or lead to personal data, with jurisdiction.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "de-leakage-assessment", "name": "Leakage assessment", "description": "Attributes disclosed by the value structure and their sensitivity.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "de-enumerability", "name": "Enumerability assessment", "description": "Whether the namespace can be systematically enumerated and with what controls.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-credential-prohibition", "name": "Credential-use prohibition", "description": "Statement that the identifier must not be accepted as an authenticator.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "de-processing-restriction", "name": "Processing restriction", "description": "A legal or sectoral restriction on processing values of this scheme, with its territory.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "privacy-classification-record", "name": "Identifier privacy classification record", "description": "Record classifying the scheme's values for personal-data status, leakage, enumerability, credential misuse and applicable processing restrictions, with the reasoning and the assessing party.", "media_or_form": [ "structured assessment record", "published statement" ], "serial": true, "identity_strategy": "Scheme registry key plus jurisdiction plus assessment version, each carrying an RFC 3339 assessment timestamp.", "source_refs": [ "SRC-018", "SRC-001", "SRC-017" ] } ], "inline_only_rationale": null } ] }, { "id": "legal-basis-and-continuity", "name": "Legal Basis, Licensing and Continuity", "description": "The instrument the scheme runs on, the terms on which its data may be used, and what happens if the operator stops.", "source_refs": [ "SRC-014", "SRC-021", "SRC-003", "SRC-019" ], "findings": [ { "id": "mandate-licensing-and-succession", "name": "Legal instrument, data licensing and succession planning", "description": "A scheme's data has terms even when it is free: the LEI system is presented as a public good available free to all users, which is itself a licensing position with consequences for downstream reuse. Registration agencies impose obligations on registrants as a condition of assignment. RFC 8126 requires change control to be settled per registry and, where entries come from many sources, per entry. ARK's observation that only a current provider can state its intended commitment makes succession the central continuity question: if the operator stops, the commitment stops unless someone has already agreed to inherit it.", "source_refs": [ "SRC-014", "SRC-021", "SRC-003", "SRC-019", "SRC-004" ], "questions": [ { "id": "q-legal-instrument", "text": "Under what legal instrument does the scheme operate, and in which jurisdictions is it effective?", "kind": "authority", "answer_data": [ "Instrument type and citation", "Jurisdictions of effect", "Any jurisdiction where it is not recognised" ] }, { "id": "q-data-licence", "text": "On what terms may the registry, assignment register and crosswalk data be used and redistributed?", "kind": "access", "answer_data": [ "Licence identifier and terms", "Distinction between single-lookup and bulk access", "Attribution and redistribution conditions" ] }, { "id": "q-registrant-obligations", "text": "What ongoing obligations bind a registrant, and what are the fees?", "kind": "requirement", "answer_data": [ "Obligation list including metadata maintenance and renewal", "Fee structure", "Consequence of non-payment or non-compliance" ] }, { "id": "q-succession-plan", "text": "Who inherits the scheme, its register and its resolution duty if the operator winds down?", "kind": "process", "answer_data": [ "Named successor or escrow arrangement", "Trigger conditions", "Whether the arrangement has been tested or exercised" ] }, { "id": "q-change-control-legal", "text": "Who holds change control over the scheme record and over individual entries?", "kind": "ownership", "answer_data": [ "Change controller at registry level", "Change controller at entry level where these differ", "Transfer procedure" ] } ], "data_elements": [ { "id": "de-legal-instrument", "name": "Legal instrument reference", "description": "Instrument under which the scheme operates, with jurisdictions.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-020" ] }, { "id": "de-data-licence", "name": "Data licence", "description": "Terms governing use and redistribution of registry, assignment and crosswalk data.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-021" ] }, { "id": "de-registrant-obligation", "name": "Registrant obligation", "description": "An ongoing duty imposed on a registrant as a condition of assignment.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "de-succession-arrangement", "name": "Succession arrangement", "description": "Named successor, escrow or wind-down arrangement for the scheme and its register.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-003" ] }, { "id": "de-fee-basis", "name": "Fee basis", "description": "Fee structure applying to registration, renewal or bulk access.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "continuity-and-licensing-record", "name": "Continuity and licensing record", "description": "Record of the scheme's legal instrument, data licence, registrant obligations, change control and succession arrangement, with evidence of any testing.", "media_or_form": [ "structured record", "governing document set" ], "serial": false, "identity_strategy": "Scheme registry key plus record version; the underlying instruments retain their own official references.", "source_refs": [ "SRC-014", "SRC-003", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "register-scheme", "name": "Register an identifier scheme", "description": "Create or amend the record that constitutes a scheme in a governing registry, capturing purpose, syntax, equivalence rules, assignment mechanism, security and privacy analysis, interoperability conflicts and resolution intent.", "inputs": [ "Completed registration template", "Pointer to a permanent public specification", "Applicant and change controller references" ], "outputs": [ "Scheme registration record with an issued registry key", "Registration status value", "Registration timestamp in RFC 3339" ], "preconditions": [ "The governing registry and its allocation policy are identified", "The proposed key satisfies the registry's syntactic constraints and is not already registered", "Any required review or specification obligation has been satisfied" ], "effects": [ "The scheme becomes citable by a stable registry key", "Downstream models may carry the scheme's namespace token", "The change controller becomes accountable for future amendment" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-003", "SRC-008" ] }, { "id": "validate-identifier-syntax", "name": "Validate a candidate identifier", "description": "Decide whether a candidate string is well formed under the scheme's grammar, repertoire and length rules and whether it passes any check element, reporting the three validity levels separately.", "inputs": [ "Candidate string", "Scheme registry key and specification version" ], "outputs": [ "Well-formedness verdict", "Check-element verdict where applicable", "Asserted validity level" ], "preconditions": [ "A machine-checkable syntax expression is available for the scheme version in force" ], "effects": [ "Malformed values are rejected before they enter a register", "A passing verdict is explicitly recorded as not evidence that the identifier has been assigned" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-019", "SRC-006" ] }, { "id": "canonicalize-identifier", "name": "Canonicalize an identifier value", "description": "Apply the scheme's own ordered normalization procedure to produce the canonical form used for storage, indexing and comparison, retaining the as-received form.", "inputs": [ "As-received identifier value", "Scheme canonicalization rule set" ], "outputs": [ "Canonical identifier value", "Record of transformations applied" ], "preconditions": [ "The scheme's normalization rules are known and versioned", "No cross-scheme generic normalizer is substituted for the scheme's own rules" ], "effects": [ "Comparison becomes deterministic within the scheme", "The as-received form remains available for provenance and dispute" ], "source_refs": [ "SRC-002", "SRC-001", "SRC-010", "SRC-019" ] }, { "id": "delegate-sub-namespace", "name": "Delegate a sub-namespace", "description": "Grant allocation authority over a portion of the namespace to another party, recording exclusivity, change control, sub-delegation rights and effective period.", "inputs": [ "Namespace portion", "Delegate reference", "Delegation terms including exclusivity and sub-delegation rights" ], "outputs": [ "Delegation register entry", "Effective period timestamps" ], "preconditions": [ "The delegating party holds authority over the portion", "The portion does not overlap an existing exclusive delegation" ], "effects": [ "The delegate may assign identifiers within the portion", "The parent retains audit reach and revocation rights as recorded" ], "source_refs": [ "SRC-003", "SRC-007", "SRC-020" ] }, { "id": "assign-identifier", "name": "Assign an identifier to a referent", "description": "Bind a well-formed identifier to a referent, recording assigner, effective time, record time, evidence, use marker and any obligatory registration metadata.", "inputs": [ "Candidate identifier or generation request", "Referent reference", "Assigner and authority basis", "Obligatory registration metadata" ], "outputs": [ "Assignment register entry", "Identifier state set to its initial value", "Effective and record timestamps in RFC 3339" ], "preconditions": [ "The identifier is well formed and not already assigned or under quarantine", "The assigner holds authority over the relevant namespace portion", "Any mandatory metadata condition has been met" ], "effects": [ "The identifier becomes usable as a reference to the referent", "Registrant obligations such as renewal and metadata maintenance begin" ], "source_refs": [ "SRC-013", "SRC-001", "SRC-015", "SRC-014" ] }, { "id": "transition-identifier-state", "name": "Transition identifier state", "description": "Move an identifier to a new state in the scheme's state vocabulary, recording trigger, actor, successor where applicable, effective time and record time.", "inputs": [ "Identifier value", "Target state", "Trigger and evidence", "Successor identifier where the transition is a supersession" ], "outputs": [ "State event log entry", "Updated current state and change timestamp" ], "preconditions": [ "The transition is permitted by the scheme's state model", "The actor is authorised to trigger it", "Any required evidence is present" ], "effects": [ "Consumers holding the identifier acquire a defined duty such as following a successor", "History is preserved rather than overwritten" ], "source_refs": [ "SRC-014", "SRC-005", "SRC-012", "SRC-003" ] }, { "id": "evaluate-reuse-eligibility", "name": "Evaluate reuse eligibility", "description": "Determine whether a retired identifier may be bound to a different referent under the scheme's reuse rule, its quarantine period and its stated exceptions, including rules that changed on a given date.", "inputs": [ "Retired identifier value", "Retirement timestamp", "Scheme reuse policy version in force at retirement and now" ], "outputs": [ "Eligibility verdict with the governing clause", "Earliest permissible reassignment time where eligible" ], "preconditions": [ "The reuse policy and its version history are recorded", "The retirement time and cause are known" ], "effects": [ "Reassignment is blocked where non-reuse applies", "Where reuse is permitted, the prior binding is retained so consumers can detect the change" ], "source_refs": [ "SRC-022", "SRC-001", "SRC-005" ] }, { "id": "resolve-identifier", "name": "Resolve an identifier", "description": "Query a resolver for the values associated with an identifier, recording the resolver consulted, the outcome class and the observation time, and interpreting failure against the scheme's declared failure semantics.", "inputs": [ "Canonical identifier value", "Resolver selection", "Optional metadata or policy request" ], "outputs": [ "Resolution outcome class", "Returned value set or metadata", "Resolution audit log entry with observation time" ], "preconditions": [ "The scheme declares resolution intent", "A resolver covering the relevant namespace portion is reachable" ], "effects": [ "The caller obtains a time-stamped result that can be reproduced or disputed", "Resolution failure is classified rather than silently treated as non-existence" ], "source_refs": [ "SRC-007", "SRC-001", "SRC-012", "SRC-002" ] }, { "id": "publish-persistence-commitment", "name": "Publish a persistence commitment", "description": "Issue a declaration by the current provider stating what is promised per dimension - identifier validity, object availability, content invariance, change history - over what horizon and with what exclusions.", "inputs": [ "Namespace portion covered", "Per-dimension promise levels and exclusions", "Committing party and horizon" ], "outputs": [ "Persistence commitment statement", "Supersession pointer to the prior statement" ], "preconditions": [ "The committing party currently controls resolution for the portion", "Any funding or legal backing for the horizon is identified" ], "effects": [ "Consumers can evaluate the promise instead of relying on the word persistent", "Custody transfer triggers a requirement to reissue" ], "source_refs": [ "SRC-019", "SRC-016", "SRC-009" ] }, { "id": "assert-cross-scheme-mapping", "name": "Assert a cross-scheme mapping", "description": "Record a typed correspondence between an identifier or scheme and its counterpart in another scheme, with asserter, evidence, quality, cardinality and chaining permission.", "inputs": [ "Source and target identifiers with their namespaces", "Relation type from a named vocabulary", "Evidence basis and asserting party" ], "outputs": [ "Mapping assertion entry", "Quality grade and chaining permission", "Assertion timestamp" ], "preconditions": [ "Both sides are canonicalized under their own scheme rules", "The relation type's symmetry, transitivity and disjointness properties are known" ], "effects": [ "Cross-scheme lookup becomes possible with a stated confidence", "Chaining is constrained so that error does not compound silently" ], "source_refs": [ "SRC-011", "SRC-015", "SRC-013" ] }, { "id": "detect-collision-and-drift", "name": "Detect collision, aliasing and drift", "description": "Scan a population of stored identifiers for duplicate denotation, uncontrolled aliasing, known unregistered use and divergence from the scheme version currently in force.", "inputs": [ "Population of stored identifier values with their carried scheme versions", "Current scheme specification and registry entry" ], "outputs": [ "Collision and drift report", "Per-item remediation status" ], "preconditions": [ "Stored values carry their namespace token and the scheme version in force at capture" ], "effects": [ "Silent divergence becomes visible and assignable to an owner", "Upstream source-standard changes can be absorbed through deprecation rather than deletion" ], "source_refs": [ "SRC-009", "SRC-005", "SRC-003", "SRC-004" ] }, { "id": "classify-identifier-privacy-risk", "name": "Classify identifier privacy risk", "description": "Assess whether values of a scheme are personal data in a given jurisdiction, what they leak, whether the namespace is enumerable, and confirm the prohibition on treating the value as an authenticator.", "inputs": [ "Scheme syntax and semantic disclosure statement", "Jurisdiction", "Intended processing purpose" ], "outputs": [ "Privacy classification record", "Required controls and processing restrictions" ], "preconditions": [ "The applicable legal regime for the jurisdiction is identified", "The structural disclosure of the identifier is documented" ], "effects": [ "Access rules and audit requirements for the identifier are set", "Misuse of the identifier as a secret or credential is explicitly foreclosed" ], "source_refs": [ "SRC-018", "SRC-001", "SRC-017", "SRC-006" ] }, { "id": "project-scheme-registry-view", "name": "Project a scheme registry view", "description": "Produce a projection over scheme records, delegations, allocation policies and resolver descriptors that omits individual assignments, for consumers who need to interpret identifiers without access to the register.", "inputs": [ "Scheme records and delegation register", "Resolver service descriptors", "Requested projection scope" ], "outputs": [ "Registry projection containing scheme keys, namespace tokens, syntax, equivalence rules and resolution intent" ], "preconditions": [ "Access scope permits scheme-level but not assignment-level disclosure" ], "effects": [ "Consuming models can validate and canonicalize without seeing assignment data", "Assignment-level confidentiality is preserved" ], "source_refs": [ "SRC-008", "SRC-013", "SRC-023", "SRC-001" ] }, { "id": "transfer-registration-authority", "name": "Transfer registration authority", "description": "Reassign change control or RA mandate when the original registrant is unreachable or an IESG or ISO decision requires it.", "inputs": [ "scheme reference", "new authority", "authorising decision" ], "outputs": [ "updated mandate", "succession event" ], "preconditions": [ "Authorising body has jurisdiction (IESG, ISO, parent RA)." ], "effects": [ "Updates change controller.", "Must not recycle already-assigned identifiers." ], "source_refs": [ "SRC-004", "SRC-026" ] } ], "composition": [ { "target": "Any Vercy model carrying identifier-valued data elements", "relation": "MIX-IN", "purpose": "Supply the carriage shape - namespace token, value, type, use marker, validity period and assigner - so that a consuming model stores an interpretable identifier instead of a bare string, and so that scheme drift is detectable at the point of use.", "required": true, "source_refs": [ "SRC-013", "SRC-010", "SRC-009" ] }, { "target": "Organization model", "relation": "REFERENCE", "purpose": "Registration authorities, oversight bodies, accredited issuers, registrants and resolver operators are organizations; this model holds only their mandate and role, never their master data.", "required": true, "source_refs": [ "SRC-014", "SRC-020", "SRC-021" ] }, { "target": "Controlled vocabulary and concept scheme model", "relation": "ALIGN", "purpose": "Align the notation carried by a concept with this model's identifier value, while leaving concept meaning, scheme membership and semantic relations to the vocabulary model; the alignment point is notation as a typed literal.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "Service and endpoint model", "relation": "REFERENCE", "purpose": "Resolver endpoints, protocols and service levels are described here as declared scheme properties and referenced to the service model for their operational reality, monitoring and incident history.", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "target": "Digital identity and authentication model", "relation": "REFERENCE", "purpose": "Record the hard boundary that an identifier is a label and never a credential; proofing, authenticator binding and authentication belong entirely to the identity model.", "required": true, "source_refs": [ "SRC-017" ] }, { "target": "Privacy and data protection model", "relation": "REFERENCE", "purpose": "Carry the privacy classification of identifier values into lawful-basis, impact-assessment and data-subject-rights processing without duplicating those processes here.", "required": true, "source_refs": [ "SRC-018" ] }, { "target": "Agreement and licensing model", "relation": "REFERENCE", "purpose": "Registration contracts, resolution service terms and bulk crosswalk licences are agreements; this model records their existence, obligations and continuity effects only.", "required": false, "source_refs": [ "SRC-014", "SRC-021" ] }, { "target": "RFC 8141 Uniform Resource Names", "relation": "ALIGN", "purpose": "Align namespace registration, equivalence procedure and the mandatory registration template fields; alignment only, since conformance for any given scheme requires an actual IANA registration as evidence.", "required": false, "source_refs": [ "SRC-001", "SRC-008" ] }, { "target": "RFC 3986 URI Generic Syntax", "relation": "ALIGN", "purpose": "Align the comparison ladder and the principle that identification does not imply access, which together fix how far a consumer may normalize and what a resolution failure means.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "RFC 8126 IANA registration policies", "relation": "ALIGN", "purpose": "Adopt the allocation policy vocabulary and the reserved-value status terms so that any scheme can state how much review its identifiers have had.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "ITU-T X.660 object identifier registration authority procedures", "relation": "ALIGN", "purpose": "Align the registration authority and hierarchical arc delegation pattern; cited only to the extent the published abstract supports, since the full text was not retrievable during research.", "required": false, "source_refs": [ "SRC-020" ] }, { "target": "HL7 FHIR Identifier datatype", "relation": "ALIGN", "purpose": "Adopt the system-plus-value carriage pattern with use, type, period and assigner as the reference shape for the mixin surface.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "SKOS mapping relations", "relation": "ALIGN", "purpose": "Adopt the mapping relation vocabulary including the deliberate non-transitivity of close matches, which constrains crosswalk chaining.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "Event and audit log model", "relation": "COMPOSE", "purpose": "Identifier state transitions and resolution attempts are events; compose the shared event structure so that effective time and observation time are always recorded separately.", "required": true, "source_refs": [ "SRC-014", "SRC-012", "SRC-003" ] }, { "target": "Referent model of the named thing", "relation": "REFERENCE", "purpose": "Every assignment points at a referent whose description, class and lifecycle belong to that referent's own model; this model asserts only the binding and its evidence.", "required": true, "source_refs": [ "SRC-013", "SRC-015" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a scheme registrar role accountable for scheme records, delegation entries and allocation policy, distinct from the registrants who own facts about their own referents.", "The Dimension must declare, for every identifier-valued element it stores, which scheme governs it and which scheme version was in force at capture, so that drift is detectable without re-deriving it from the value.", "The Dimension must publish its own canonicalization rule set per adopted scheme and must not apply a generic cross-scheme normalizer, because equivalence rules differ materially between schemes.", "The Dimension must record assignment effective time and record time separately, in RFC 3339 with an explicit offset or Z.", "The Dimension must state, per adopted scheme, whether resolution is available to it and what a resolution failure is taken to mean, so that failure is never silently read as non-existence.", "The Dimension must classify each adopted scheme for personal-data status in every jurisdiction where it operates before storing values at scale." ], "namespace_guidance": "Namespaces are declared, not inferred. A scheme's namespace token is an absolute URI, a registered namespace identifier, or a registered numeric code designator, and the Dimension must state which token is canonical for exchange. Local prefixes and abbreviations are document-scoped placeholders only and must be expanded to the full token whenever a name leaves its containing document. Where the Dimension mints its own scheme it must not squat on an unregistered token, must not use a name that implies a registration it does not hold, and must record the token as locally scoped until a registration exists.", "registry_links": [ "The governing registry entry for each adopted scheme, cited by registry name, key and reference document", "The Dimension's own scheme register listing every scheme it consumes, with adopted version, canonicalization rule set version and privacy classification", "The delegation register for any namespace portion the Dimension has been delegated or has itself delegated", "The crosswalk mapping sets the Dimension relies on, with asserter, quality grade and chaining permission" ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form is scheme-specific and is produced only by that scheme's own ordered rule set; a rule set is versioned and referenced by version, never by date alone.", "The as-received value is retained alongside the canonical value; canonicalization never destroys the input.", "Percent-encoded or escaped octets are never decoded during canonicalization unless the scheme's own rules require it, because decoding can merge distinct identifiers.", "Optional trailing components reserved for resolution or fragment purposes are excluded from equivalence comparison unless the scheme states otherwise.", "Timestamps in scheme, assignment, state and resolution records are canonicalized to RFC 3339 with seconds and an explicit offset or Z." ], "patch_rules": [ "Scheme records, delegation entries and assignment records are amended by additive patch; historical entries are deprecated with a dated marker and an optional successor pointer, and are never removed.", "A patch that changes a scheme's syntax, equivalence rules or reuse policy must carry an effective timestamp and must state whether values assigned under the prior version are grandfathered.", "A patch to an assignment binding must preserve the prior binding record so that a consumer holding the old reference can detect the change.", "Patches to entries with a distinct entry-level change controller require that controller's approval, not merely registry-level approval.", "Every patch records actor, effective time and record time separately." ], "compatibility_rules": [ "Changing a scheme's canonicalization rule set is a breaking change for every stored comparison and requires revalidation of affected populations before the new rules take effect.", "Adding a state value to the identifier state vocabulary is compatible; removing one or redefining an existing transition is breaking.", "Relaxing a grammar is compatible for validation but breaking for any consumer that relied on structural inference; such relaxations must be announced with the inferences they invalidate.", "Moving a scheme from permitting reuse to forbidding it is compatible forward but must not be applied retroactively to values already reassigned under the prior rule.", "A crosswalk relation may be weakened from exact to close without notice only if chaining permission is simultaneously withdrawn." ] }, "artifact_rules": { "identity_priority": [ "The identifier issued by the authoritative master system for the artifact's subject - for a scheme record, the key issued by its governing registry; for an assignment, the assigned identifier itself.", "A governed global identifier or IRI where no master-system key exists - the scheme's registered namespace URI, or a registered persistent identifier for a published report or dossier.", "A UUID or ULID assigned by the adopting Dimension, explicitly recorded as locally scoped and carrying no external authority.", "A date, a title, a file path or a storage location is never an identifier and must not be used as one, even provisionally." ], "timestamp_rule": "All time values are recorded in RFC 3339 format with seconds and an explicit UTC offset or Z. Event time - when an assignment took effect, when a state changed, when a commitment was made - is recorded separately from observation or ingestion time, and neither may be inferred from the other.", "serial_naming_rule": "Serial artifacts carry a monotonically increasing sequence number within a named series scoped to the scheme registry key, plus the RFC 3339 issue or observation timestamp of the instance. The sequence number identifies position in the series; the timestamp identifies the instance in time. Neither alone is sufficient, and a serial artifact is never identified by its period label alone.", "integrity_rule": "Every artifact records the scheme registry key and scheme specification version it was produced against, the actor that produced it, and the source references supporting its claims. Registers, event logs and audit logs are append-only: corrections are issued as new entries that supersede prior ones explicitly rather than by overwriting. Any artifact asserting conformance must cite the standard, edition and clause together with the evidence, or downgrade the claim to an alignment." }, "policies": [ "Conformance to an external standard is never asserted without cited evidence naming the edition and clause; absent evidence, the relationship is recorded as an alignment with its divergences enumerated.", "Identifier values are never accepted as evidence of authorisation, authenticity or identity; any system that treats an identifier as a secret is recorded as a defect requiring remediation.", "Non-reuse is not assumed. The reuse rule, its quarantine period, its exceptions and the effective date of every rule version are recorded per scheme, and a consumer holding a long-lived reference is told how to detect a change of referent.", "Comparison of identifiers is performed only with the governing scheme's own rules; a generic normalizer must not be applied across schemes.", "Persistence claims are recorded as commitments by a named current provider, with per-dimension promises and a horizon; the unqualified word persistent is not accepted as a value.", "Bulk export of assignment registers and crosswalk tables is audited, and the personal-data classification of the exported scheme is checked before release.", "Scheme definitions and public registry status are readable by default; assignment evidence, authorised representations and licensed bulk crosswalks are restricted to the respective owner.", "Uniqueness and reassignment policy of the scheme of record prevails over catalogue convenience; URN-like schemes never recycle names.", "Physical deletion of assignment records is forbidden where retirement semantics require tombstones, old identifiers for matching, or audit; otherwise deletion follows the records-retention sibling after cooling-off.", "Agents MUST NOT construct URNs from native non-URN names unless they implement the namespace-specific canonicalisation rules." ], "crud": { "read": [ "Scheme records, syntax, equivalence rules, allocation policy and resolution intent are readable by any agent that must interpret an identifier, without access to assignment data.", "Assignment records are readable according to the personal-data classification and licence of the governing scheme, defaulting to the narrower of the two.", "Resolution and state event logs are readable by the scheme registrar and by auditors; consumers read the current state through the published state query rather than the log.", "Every read of an assignment record returns the observation time so that staleness is assessable." ], "create": [ "A scheme record may be created only by the scheme registrar, and only once the governing registry, allocation policy and canonicalization rule set are identified.", "An assignment may be created only by a party holding authority over the relevant namespace portion, with the referent reference, effective time and any mandatory metadata present.", "A delegation entry may be created only by a party that itself holds authority over the portion and only where it does not overlap an existing exclusive delegation.", "A mapping assertion may be created by any party but is stored with its asserter, evidence basis and quality grade; unattributed mappings are rejected." ], "update": [ "Updates are additive: a new state, a new version, a new assertion. Prior values are retained with dated deprecation markers.", "A change to a scheme's syntax, equivalence or reuse policy requires an effective timestamp and a grandfathering statement, and triggers revalidation of stored populations.", "An assignment's referent binding is never silently changed; a change of referent is modelled as retirement plus, where permitted, a new assignment with the prior binding retained.", "Entry-level change controllers must approve updates to entries they control, even where the registrar holds registry-level change control." ], "delete": [ "Scheme records, assignment records and registry entries are not deleted. They are deprecated or obsoleted with a dated marker and, where applicable, a successor pointer.", "Physical removal occurs only to satisfy a legal erasure obligation, and then only for the personal data within a record, leaving a tombstone that records that a removal occurred, under which instrument and when.", "A tombstone must remain resolvable where the scheme's persistence commitment covers identifier validity, so that a consumer learns the referent is gone rather than that the identifier is unknown.", "Deletion of a delegation entry is prohibited while identifiers issued under it remain in any state other than annulled." ] }, "roles": [ { "name": "Scheme registrar", "responsibilities": [ "Own scheme records, syntax and equivalence rule sets, allocation policy and delegation entries", "Approve and publish amendments with effective timestamps and grandfathering statements", "Maintain the register of adopted schemes and their versions for the Dimension", "Publish the collision and drift report and assign remediation owners" ] }, { "name": "Allocation authority or accredited issuer", "responsibilities": [ "Assign identifiers within a delegated namespace portion and record assigner, evidence, effective and record times", "Enforce uniqueness, quarantine and reuse eligibility before binding", "Maintain mandatory registration metadata conditions on registrants", "Report allocation rates for capacity forecasting" ] }, { "name": "Registrant", "responsibilities": [ "Own the facts about the referent an identifier denotes and keep required metadata current", "Meet renewal or revalidation obligations before lapse", "Notify the issuer of referent transfer, withdrawal, split or merge", "Accept the recorded conditions of assignment" ] }, { "name": "Resolution operator", "responsibilities": [ "Operate resolver endpoints within a declared coverage and service level", "Publish and honour the persistence commitment for the portions it currently controls, including tombstone behaviour", "Record resolution outcomes with observation times for audit", "Reissue or transfer commitments when custody changes" ] }, { "name": "Mapping steward", "responsibilities": [ "Assert and maintain cross-scheme mappings with relation type, evidence, quality and chaining permission", "Withdraw mappings when either side is deprecated or reassigned", "Measure and publish mapping quality and known systematic errors", "Prevent uncontrolled transitive inference across chained mappings" ] }, { "name": "Assurance and privacy reviewer", "responsibilities": [ "Classify each adopted scheme for personal-data status, leakage and enumerability per jurisdiction", "Verify that conformance claims cite standard, edition, clause and evidence, and downgrade unsupported claims to alignments", "Audit bulk exports of assignment and crosswalk data", "Confirm that no system accepts an identifier value as an authenticator" ] } ], "access": { "default_rule": "Scheme-level context is open to any agent that must interpret an identifier; assignment-level context is closed by default and released only by the owner of the referent facts, under the narrower of the governing scheme's licence and its personal-data classification.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Assignment registers for schemes classified as personal data are restricted to purposes recorded in the privacy classification record, with national identification numbers additionally subject to the restrictions of the territory concerned.", "Bulk export of assignment registers or full crosswalk tables requires explicit owner approval and is audited per export, regardless of whether single-record lookup is open.", "Evidence artefacts supporting an assignment may be more sensitive than the assignment itself and are released separately.", "Resolution and state event logs are restricted to the registrar and auditors, because access patterns over them can disclose interest in a referent.", "Where a scheme is enumerable, rate limits and harvesting monitoring apply even to otherwise open scheme-level reads.", "National-library or similarly authorised resolution may return metadata to the public and representations only to entitled callers.", "Third-party registration of an observed-in-the-wild unregistered URI scheme may identify both the registering party and the scheme creator.", "Emergency IESG or parent-RA reassignment of a contact-lost provisional scheme." ], "audit_requirements": [ "Every bulk export records requester, scope, licence relied upon, personal-data classification checked and RFC 3339 export time.", "Every amendment to a scheme record, delegation entry or reuse policy records actor, effective time and record time, and is retained after supersession.", "Every resolution attempt used as evidence in a decision records the resolver consulted, outcome class and observation time.", "Every legally mandated erasure records the instrument, the scope removed and the tombstone left behind.", "Audit records are append-only and are retained for at least the persistence horizon declared for the affected namespace portion.", "Log scheme registration, namespace delegation, assignment, status change, resolver-endpoint change and bulk crosswalk export with event time, actor and ingestion time.", "Resolution requests are audited when the scheme or contract requires it, especially for access-controlled representations." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Scheme registry key", "Governing registry", "Canonicalization rule set version", "Reuse policy version and effective date", "Personal-data classification and jurisdiction", "Change controller" ], "read_order": [ "AGENTS.md - identify the model, its type, and the four URLs before touching any content", "Specification URL - scope, boundaries and the bundle, layer and finding structure, so that a finding is never confused with a file", "Storage type URL - how records are physically held, noting that the storage form is a projection and carries no semantics", "Interface URL - how to read and write, including which scopes are open and which require owner approval", "Processes URL - the operating procedures for registration, delegation, assignment, state transition, resolution, mapping and export", "Scheme register of the adopting Dimension - which schemes are adopted, at which version, with which canonicalization rules and privacy classification", "Reuse and persistence policy statements for any scheme whose identifiers will be stored as long-lived references" ] } }, "coverage": { "claim": "Dual-provider research synthesis: standards-led Claude structure plus evidence-backed Grok additions. Structurally complete for a draft Identifier Scheme mixin; listed external-family omissions remain deferred and no universal completeness is claimed.", "confidence": "medium", "checklist": [ { "dimension": "Identity", "status": "covered", "notes": "Scheme identity via governing registry key with namespace expression fallback; assignment identity via namespace plus canonical value. Identity priority and the prohibition on dates as identifiers are enforced in artifact rules. Grounded in the IANA URN namespace registry, BCP 35 and the FHIR Identifier shape." }, { "dimension": "Classification", "status": "covered", "notes": "Referent class, scheme registration status, opacity class, identifier use and type markers, reserved and private-use ranges, and personal-data classification all carry coded values from named vocabularies rather than free text." }, { "dimension": "Composition", "status": "covered", "notes": "Structural components of an identifier, delegation trees, sub-namespaces and split or merge of referents. The Handle naming authority tree and the DOI prefix-suffix division are the concrete grounding." }, { "dimension": "Relationships", "status": "covered", "notes": "Cross-scheme mapping with SKOS relation semantics including non-transitivity of close matches, DataCite supersession relations, alias and preferred-identifier designation, and delegation chains." }, { "dimension": "State and lifecycle", "status": "covered", "notes": "Explicit state vocabulary and transition model grounded in the LEI registration statuses, the BCP 47 deprecation and preferred-value mechanics, RFC 8126 reserved and unassigned status terms, and the DID deactivate operation." }, { "dimension": "Temporal", "status": "covered", "notes": "Assignment effective time separated from record time, state change separated from state observation, resolution observation time, quarantine durations, renewal due times, policy effective timestamps and commitment horizons, all in RFC 3339 with explicit offset." }, { "dimension": "Spatial", "status": "covered", "notes": "Handled as jurisdiction and territorial scope of mandate, of processing restriction and of licence, not as geometry. No geographic coordinate content applies to a naming system; the ISO 6523 issuing-agency country field and GDPR Article 87 Member State reservation are the grounding." }, { "dimension": "Provenance", "status": "covered", "notes": "Asserter and evidence on every mapping, assigner and evidence reference on every assignment, as-received value retained beside canonical value, and append-only event logs with actor and dual timestamps." }, { "dimension": "Ownership", "status": "covered", "notes": "Change controller at registry and entry level, registrant ownership of referent facts distinct from registrar ownership of scheme records, and custody transfer for both referents and resolvers." }, { "dimension": "Authority", "status": "covered", "notes": "Mandate instrument, oversight body, issuer accreditation, delegation and sub-delegation rights, allocation policy naming, and the explicit question of what happens when the mandate holder fails." }, { "dimension": "Constraints and requirements", "status": "covered", "notes": "Grammar, repertoire, length, check systems, equivalence and comparison level, reuse and quarantine, chaining limits, registrant obligations and the standing prohibition on credential use." }, { "dimension": "Process and events", "status": "covered", "notes": "Thirteen functions covering registration, validation, canonicalization, delegation, assignment, state transition, reuse evaluation, resolution, commitment publication, mapping, drift detection, privacy classification and registry projection, each with preconditions and effects." }, { "dimension": "Measurement", "status": "covered", "notes": "Namespace capacity, allocation rate, projected exhaustion, accepted collision probability, defect rates and mapping quality grades, each required to carry its measurement method or population." }, { "dimension": "Evidence and quality", "status": "covered", "notes": "Three separated validity levels, conformance claims required to cite edition and clause or be downgraded to alignment, audit regime, defect measurement and remediation path." }, { "dimension": "Access and exceptions", "status": "covered", "notes": "Scheme-level open and assignment-level closed by default, five named exception classes, five audit requirements, and the erasure-versus-persistence conflict handled explicitly through tombstones." }, { "dimension": "Interoperability", "status": "covered", "notes": "Carriage profile as the mixin surface, namespace token canonical form, local-only prefixes, scheme version carried with every stored value, and the filed interoperability-conflict statement from the registration template." }, { "dimension": "Security", "status": "gap", "notes": "Covered only where the retrieved sources speak: leakage, enumeration and the prohibition on credential use. Resolver spoofing, registry compromise, cryptographic binding of an identifier to its referent, and signature or key-rotation practice for self-certifying identifiers are not developed, because the DID method-level security requirements were retrieved only as headings." }, { "dimension": "Cost and commercial terms", "status": "covered", "notes": "Fee basis, data licence, bulk access distinction and registrant obligations, grounded in the LEI public-good position and the registration agency model; treated thinly because primary sources on pricing were not retrieved." } ], "known_omissions": [ "ISO/IEC 11179-5 and 11179-6 on naming and registration principles, ISO/IEC 7064 on check character systems, ISO/IEC 6523 itself, ISO 26324, ISO 17442 and ISO 15511 could not be read directly; the ISO catalogue and browsing platform returned 403 throughout. Their content is reflected only through accessible first-party or downstream sources, and no clause-level claim is made about any of them.", "The full text of ITU-T X.660 was not retrievable; object identifier arc allocation, unambiguous name rules and the international registration authority's procedures are asserted only at the level the published abstract supports.", "The GS1 General Specifications full text exceeded the retrieval limit; the check digit calculation and company prefix exclusivity rule are known only through GS1 summary pages, and the non-reuse rule through a first-party support article citing section 4.2.5.", "The ISO/IEC 6523 registration authority site was unreachable over HTTPS with an expired certificate; the ICD list is represented through a Peppol rendering, which is a downstream operational view rather than the register of record.", "Whole identifier families were not researched: E.164 telephone numbering, postal and addressing codes, content-addressed identifiers such as multihash and CID, blockchain address schemes, biometric and behavioural identifiers, radio callsigns and spectrum registrations, and vehicle or aircraft registration schemes.", "Machine-readable scheme description languages and the tooling that consumes them were not surveyed, so the model does not state how a scheme's syntax and equivalence rules should be published for automated use.", "Economic and antitrust aspects of monopoly registries, and the dispute resolution procedures that mature registries operate, are represented only as questions without grounded answer structures.", "ITU-T E.164 telephone numbering, number portability and reuse cooling-off were not fetched as primary text and are flagged as a likely reuse-policy omission.", "ITU-T X.660 / ISO/IEC 9834 OID arc administration is only indirectly supported via urn:oid and FHIR oid, not as a full RA model.", "W3C CURIE and prefix.cc community prefix governance lack a primary fetch in this run.", "NISO, DataCite kernel, ORCID and ISNI merge procedures are discovered via IANA NID entries but not specified here as first-party operating manuals.", "DID v1.1 Candidate Recommendation Snapshot of 5 March 2026 is emerging and not the alignment target.", "Handle DO-IRP 2022 is cited from the DOI Handbook rather than fetched as a DONA primary.", "Jurisdiction-specific civil identifiers (national ID, tax ID) are out of content scope; scheme-level privacy rules still apply if such a scheme is registered.", "Quantum-resistant identifier cryptography and ledger-specific DID method suites are not specified." ], "conflicts": [ "Non-reuse is not universal. RFC 8141 section 5.1 asks a formal-namespace registrant to demonstrate a commitment not to reassign, and BCP 47 section 3.4 guarantees subtags are never removed or reassigned; GS1 by contrast operated timed reuse until an all-sector non-reallocation rule took effect after December 2018 and still permits reuse twelve months after catalogue deletion for never-produced items. The model therefore records reuse as a per-scheme policy with versions and exceptions, not as an invariant.", "Equivalence rules are mutually incompatible across schemes. RFC 3986 section 6 offers a graded normalization ladder, RFC 8141 section 3.1 forbids percent-decoding and requires optional components to be ignored, Namespaces in XML section 2.3 requires identical character sequences with no escaping done or undone, and ARK treats hyphens as insignificant and lowercases the authority number. No single generic normalizer is correct; the model makes canonicalization scheme-scoped.", "Opacity guidance conflicts with delegated-prefix design. W3C web architecture section 2.5 advises agents not to infer properties of a referent from its identifier, and ARK strongly encourages semantic opacity, yet DOI prefixes, LEI issuer prefixes, GS1 company prefixes and Handle naming authorities all deliberately encode the issuer, and real systems parse them. The model resolves this by recording permitted and forbidden inferences per scheme rather than adopting either position.", "The name-versus-locator partition is contested. RFC 3986 section 1.1.3 states that a scheme need not be classified as just one of name or locator and recommends the general term URI, while the DOI, Handle and ARK communities maintain a strong separation of identifier from location as a design principle.", "SKOS declares exactMatch transitive and symmetric while deliberately withholding transitivity from closeMatch to stop errors compounding. In practice crosswalks are chained across schemes regardless, so a formally valid transitive inference can still produce a wrong correspondence. The model carries an explicit chaining permission flag rather than relying on the formal semantics alone.", "Persistence expectations conflict with erasure obligations. FAIR A2 asks that metadata remain accessible even when the data are gone, and ARK persistence declarations may promise identifier validity indefinitely, while GDPR erasure rights can require removal of personal data from a record that a persistence commitment says will endure. The model handles this with tombstones and an explicit reconciliation decision record, but the conflict is real and jurisdiction-dependent.", "DID design goals reject centralized authorities and single points of failure, yet DID methods are themselves registered and each must specify create, resolve, update and deactivate operations. The registration authority function is displaced into method governance rather than eliminated, which the model treats as a variant of authority rather than its absence.", "Case sensitivity is scheme-specific and cannot be generalised: URN namespace identifiers are case-insensitive, DOI names are case-insensitive, XML namespace names are case-sensitive, and ARK lowercases only the authority number.", "RFC 8141 uniqueness never reassigns a name; FHIR old/temp and many telecom/domain schemes permit reuse or former-identifier matching. Record the scheme policy; do not globalise URN rules.", "RFC 8141 restricts URNs to ASCII with percent-encoding; RFC 3987 IRIs share the URI scheme registry. A scheme may have both forms only if its specification says so.", "ISO 26324: a DOI does not replace other ISO/TC 46 identifiers even when it encapsulates their strings.", "DID Core: UUIDs are not resolvable or cryptographically verifiable; treating urn:uuid as a DID method is a conflict.", "SKOS exactMatch versus owl:sameAs: mappings of identifiers or notations are not identity of referents.", "RFC 8141 r-components are syntactically defined but SHOULD NOT be used until their semantics are standardised.", "Microsoft COM GUID little-endian layout versus RFC 9562 network byte order.", "Historical URI schemes remain in IANA with status historical; absence from common use is not deletion." ], "regional_assumptions": [ "The personal-data framing follows Regulation (EU) 2016/679, which applies to the EU and EEA. Article 87 expressly leaves national identification numbers to Member State law, so identifier-specific restrictions vary within the EU itself. Other regimes - United States sectoral rules including health identifiers, Brazil, India, China and others - impose different and sometimes incompatible constraints that were not researched.", "The ISO 6523 code designator list is represented through a Peppol BIS Billing rendering, which reflects European cross-border electronic invoicing practice and may omit or reorder entries relative to the register of record.", "The LEI governance model reflects a G20-backed supranational arrangement; national organization identifier schemes cited in the same code list operate under wholly different mandates, funding and public-access terms.", "Retrieval itself was regionally constrained: several standards bodies returned 403 to automated access from the research environment, which biases the evidence base toward IETF, W3C and openly published first-party sources and away from ISO, IEC and ITU normative text.", "Language and script assumptions are not neutral: the retrieved sources overwhelmingly constrain identifiers to ASCII or a restricted graphic repertoire, and internationalised identifier handling was not researched beyond the DOI statement about Unicode graphic characters.", "IANA and ISO registries are treated as globally authoritative for the scheme classes they govern; national bibliographic or eID schemes may add regional RAs not listed here.", "ARK NAAN registry hosting at CDL with mirrors at NLM and BnF is the current operational assumption, not a metaphysical lock-in.", "GS1 check-digit rules as published by GS1 AISBL are used; national GS1 member organisations may add allocation policy.", "English official names are stored as names; other language designations belong in a naming-convention sibling aligned with ISO/IEC 11179-5." ], "adversarial_checks": [ "Tested whether an identifier scheme is merely a code list, using SKOS. A concept scheme governs meaning and is explicitly open-boundaried, with notation as a typed literal labelling a concept; an identifier scheme governs denotation and uniqueness over referents. The distinction holds for opaque schemes but blurs for standards such as ISO 3166 that both classify and denote, so this is recorded as an unresolved boundary rather than a clean separation.", "Tested the claim that identifiers are never reused. Falsified: GS1 permits reuse twelve months after catalogue deletion for never-produced items and grandfathers pre-2019 discontinuations, and RFC 8141 states only that a registrant should demonstrate a commitment. The model was restructured to carry reuse as a versioned per-scheme policy with exceptions.", "Tested whether equivalence could be a single generic function. Falsified by four mutually incompatible normalization regimes across RFC 3986, RFC 8141, Namespaces in XML and ARK. Canonicalization was moved inside the scheme and a compatibility rule added making a rule-set change a breaking change.", "Tested whether resolution success or failure is evidence about the referent. Falsified by RFC 3986 section 1.2.2, which states that access is neither guaranteed nor implied. A separate finding fixes failure semantics so that failure cannot be read as non-existence, and it is deliberately carried inline because the resolution statement already lives in the registration record.", "Tested whether a self-generated UUID is a sufficient identity strategy. RFC 9562 requires collision consequences to be reasoned about and offers only local or global uniqueness depending on deployment; more decisively, a UUID has no registration authority and so cannot satisfy any requirement for an authority of record. It is therefore ranked third in identity priority and must be marked locally scoped.", "Tested whether DIDs falsify the registration authority concept. Partially only: methods are registered and each must define create, resolve, update and deactivate, so authority is relocated into method governance. The model treats decentralised methods as a variant, not a counterexample.", "Tested whether the previous-version material could be adopted as-is. Its three-bundle shape omitted equivalence and canonicalization, opacity, capacity and exhaustion, persistence commitments as distinct from resolution services, privacy classification, conformance evidence and succession planning - each of which is required or strongly implied by a retrieved primary source. The structure was rebuilt rather than extended.", "Tested whether a date could serve as an identifier for any artifact in this model, since serial reports and policy versions are commonly named by period. Rejected: a reporting period does not uniquely denote an instance across reissues, so serial artifacts are keyed by series-scoped sequence number plus an RFC 3339 issue timestamp.", "Would a date such as 2026-08-22 be accepted as a scheme or assignment identifier? No; identity priority forbids it.", "Would constructing a URN ISBN from a native ISBN without namespace canonicalisation be allowed? No; RFC 8141 forbids unaware construction.", "Would marking a DID deactivated be treated as deleting the identifier string and allowing reuse? No; deactivation is not URN-style deletion nor automatic recycling.", "Would two strings that differ only in a q-component be treated as different URNs? No; RFC 8141 ignores r/q/f-components for equivalence.", "Would a bulk SKOS exactMatch export be treated as merging organisations or works in the referent models? No; mapping quality is not referent identity." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both independent providers distinguish the governed identifier scheme, assignment and resolution semantics from the referent, generic organization, service endpoint and storage/interface models." }, "decisions": [ { "concept": "Six-bundle core", "disposition": "accepted-from-both", "rationale": "Both passes converge on scheme definition, authority, assignment/lifecycle, resolution, mapping/interoperability and assurance concerns despite different labels." }, { "concept": "Assurance, privacy and legal continuity", "disposition": "accepted-from-claude", "rationale": "The independent Grok pass covers access and privacy in service rules, while Claude provides a properly bounded subject bundle grounded in GDPR, NIST and persistence evidence." }, { "concept": "Namespace capacity and exhaustion", "disposition": "accepted-from-claude", "rationale": "Capacity affects allocation continuity and appears in mature naming systems; it remains scheme policy rather than a global numeric invariant." }, { "concept": "Split, merge and alias continuity", "disposition": "accepted-from-grok", "rationale": "This closes non-linear lifecycle cases omitted by the base finding." }, { "concept": "Non-reuse invariant", "disposition": "rejected-as-global", "rationale": "URN and BCP 47 permanence conflicts with schemes that permit reassignment; reuse, quarantine and exceptions must be versioned per scheme." }, { "concept": "Universal identifier normalizer", "disposition": "rejected", "rationale": "URI, URN, XML Namespace, ARK, DOI and other schemes use incompatible case, escaping and component-equivalence rules." }, { "concept": "Identifier as credential", "disposition": "rejected", "rationale": "Both security-oriented evidence and model boundaries require authentication and authorization to remain separate from identifier possession." } ], "publicationHolds": [ "Verify live availability, version and exact claim support for every source accepted into the synthesis.", "Resolve or explicitly scope the deferred identifier families before promoting a claim of catalogue completeness." ], "deferredResearch": [ "E.164 numbering, number portability, reuse cooling-off and jurisdictional mandates.", "Content-addressed identifiers such as multihash and CID, ledger addresses and quantum-resistant identifier suites.", "Direct clause-level verification of paywalled ISO/IEC 11179, 7064, 6523, 9834, ISO 26324 and ISO 17442 texts.", "Machine-readable scheme-description languages and automated publication tooling.", "Registry dispute resolution, monopoly-registry economics and antitrust constraints." ] }, "statistics": { "sources": 33, "bundles": 6, "layers": 20, "findings": 29, "questions": 130, "artifacts": 27, "functions": 14 } }