Governance Framework for Embedded Semantics Concept Registries: Designing Trustworthy and Durable Semantic Infrastructure

Full report

On this page

1. Executive Summary

The transition toward registry-backed semantic resolution introduces an architecture where probabilistic machine learning models, such as vector embeddings, are intentionally decoupled from authoritative semantic meaning. In the Embedded Semantics paradigm, persistent concept records define specific meanings, while natural language expressions serve as governed, heavily reviewed evidence mapping to stable, unique identifiers known as ConceptCodes1. Because language embeddings constantly drift due to model upgrades, periodic retraining, and natural language evolution over time, a durable semantic identity must be anchored in an immutable, deeply governed registry1. This ensures that the meaning of a data element survives across decades of technological shifts, remaining entirely independent of the retrieval algorithms used to initially surface it. This report provides an exhaustive governance specification for an Embedded Semantics Concept Registry, designed to support long-lived enterprise and public infrastructure. Drawing on the architectural successes of high-trust global infrastructures—such as the Unicode Consortium's stringent stability policies, SNOMED CT's append-only historical tracking mechanisms, GS1's strict non-reuse principles, the W3C's namespace persistence doctrines, and the cryptographic transparency logs utilized by Sigstore—this specification outlines a governance model optimized for total auditability, deterministic reversibility, and the absolute preservation of semantic meaning3. The overarching objective is to establish an institutional-grade governance model capable of managing multilingual semantic identities, ensuring that downstream software systems can rely on these ConceptCodes for decades without fear of silent semantic corruption.

2. Governance Principles

The governance of a semantic registry must prioritize the preservation of historical meaning over any administrative convenience. The foundational architecture relies on principles adapted from the world's most durable standard bodies, dictating the operational and architectural limits of the system. The foremost principle is the absolute immutability of meaning, modeled directly after the Unicode Consortium's Name Stability Policy3. Once a ConceptCode is published and integrated into the global registry, its fundamental meaning must never change, as altering the definition would instantly invalidate all historical data that utilized the code under its original premise8. If a concept is later discovered to be deeply ambiguous, the registry must deprecate the concept and issue entirely new, distinct ConceptCodes rather than silently shifting the definition of the existing identifier. To support this immutability, the registry must enforce an append-only provenance model. Following the SNOMED CT Release Format 2 (RF2) architecture, the registry must operate as an append-only log where no record is ever physically deleted from the underlying database5. State changes, such as the deprecation of a concept or the removal of an expression binding, are recorded as new rows with updated effective timestamps and activation flags, preserving a perfect historical timeline5. Furthermore, the governance model requires the irrevocability of identifiers. Similar to the GS1 Global Trade Item Number (GTIN) non-reuse policy implemented globally in 2019, a ConceptCode, once assigned and published, can never be reused or reassigned to a different semantic concept, even if the original concept was published in error and immediately withdrawn7. This is because digital trade items and semantic identities persist in decentralized logs indefinitely; recycling an identifier introduces catastrophic ambiguity into historical datasets12. Finally, the registry must enforce the separation of semantics from implementation constraints, drawing heavily from ISO/IEC 11179 metadata registry standards14. The governance of the semantic meaning must remain strictly independent of specific software implementations, database schemas, or downstream application logic. Every mutation within this isolated semantic layer must be cryptographically signed and recorded in a verifiable transparency log, echoing the Sigstore and Rekor models for software supply chain security, guaranteeing that no central administrator can alter the semantic consensus without detection4.

3. Actor/Role Model

A robust metadata registry requires distinct roles to prevent unilateral capture and to ensure rigorous peer review. The proposed actor model adapts the ISO/IEC 11179 registry roles and the IETF RFC 8126 Designated Expert guidelines to create a hierarchy of trust and capability17. Reviewers and experts establish competence not through anonymous contributions, but through cryptographically verifiable organizational affiliations and demonstrated domain expertise, mapping to established identity providers18.

4. Concept Lifecycle

The lifecycle of a ConceptCode must reflect the strict append-only paradigm mandated by the governance principles. A concept represents a distinct meaning, decoupled from the natural language words used to express it1. The lifecycle relies heavily on the effectiveTime and active boolean model derived directly from the SNOMED CT RF2 specification to track validity without ever relying on destructive database operations10. A ConceptCode begins as a draft proposal, supported by rigorous evidence defining its precise semantic boundaries. Upon approval by a qualified Reviewer, a transaction is appended to the log, and the concept transitions to an active state. If a concept is later deemed to be a duplicate, technically obsolete, or fundamentally ambiguous, the original record cannot be modified or deleted. Instead, a completely new lifecycle event is appended to the cryptographic log, setting the concept's active flag to false5. This inactivation row must be accompanied by a mandatory reason code indicating the nature of the deprecation, such as erroneous, ambiguous, duplicate, or outdated21. Downstream systems querying the registry will parse this historical record, ensuring that legacy data annotated with the deprecated ConceptCode remains fully interpretable, while new data is routed toward active concepts.

5. Expression Lifecycle

Expressions are the natural language strings acting as governed evidence for a specific concept1. Because natural language constantly evolves, the expression lifecycle is highly dynamic, whereas the underlying ConceptCodes remain rigidly stable. When a Submitter proposes that a specific multilingual expression represents a ConceptCode, this mapping requires its own independent governance lifecycle. The expression mapping must include a strict language constraint, dialect specifications if necessary, and citations from an authoritative corpus proving usage1. Expressions can be added, refined, or deprecated independently of the concept they represent. If a previously accepted expression undergoes semantic drift in popular usage—such that it begins to mean something entirely different to the general public—the mapping to the original ConceptCode is deprecated. A new mapping is then proposed to a more accurate ConceptCode. This ensures the Concept Registry resolves contemporary language accurately while seamlessly preserving the historical mappings that governed older, archival texts.

6. Review-State Machine

The registry utilizes a strict state machine to govern the transition of Concepts and Expression Mappings. Three distinct review levels exist: automated sanity checks, peer review by a Steward, and escalated review by a Designated Expert for complex boundary disputes18.

7. Provenance Fields

To guarantee institutional trust, every mutation in the registry must contain a comprehensive, cryptographically verifiable provenance record. Following software supply-chain security best practices, the registry schema must include specific immutable fields for every transaction, ensuring it is immediately clear who reviewed a decision, when it occurred, and under what policy4.

8. Evidence Requirements

The determination of what constitutes sufficient evidence for an expression-to-concept equivalence is the most critical qualitative function of the registry. Because the registry cannot rely on probabilistic model embeddings as an authoritative semantic source of truth, evidence must be highly deterministic, documented, and independently verifiable by third parties1. For the minting of an entirely new Concept, sufficient evidence includes a clear, disambiguated natural-language definition and formal references to existing, respected ontologies (such as Wikidata, SNOMED CT, or the Dublin Core) where applicable22. For an expression mapping to be considered valid evidence of equivalence, the Submitter must demonstrate widespread, unambiguous usage of the string to represent the specific concept in the real world. This requires formal citations from authoritative dictionaries, domain-specific literature, or structured semantic webs. The evidence must unequivocally prove that the expression, within the specified language constraints, maps precisely to the ConceptCode's definition without significant polysemy that would break downstream determinism. If an expression is commonly used to mean three different things, it cannot serve as exact equivalence evidence for just one of them without heavily constrained contextual metadata.

9. Multilingual Review Policy

Multilingual identity is a foundational pillar of the Embedded Semantics architecture1. Ensuring parity across diverse languages introduces the severe risk of subtle semantic drift, as direct translations often carry differing cultural, legal, or technical nuances that do not map cleanly to a single universal concept. To mitigate this drift, multilingual reviews absolutely require native-language Reviewers who possess demonstrated domain expertise in both the source and target languages. Automated machine translation is strictly prohibited as a basis for declaring semantic equivalence. When evaluating whether an expression in a new language maps to an existing ConceptCode, the Reviewer must verify that the extension of the concept in the target language perfectly aligns with the original definition. If the target language expression encompasses a broader or narrower semantic scope than the original ConceptCode allows, a new, distinct ConceptCode must be created. These two distinct concepts are then linked via a formal relationship (such as broader than or narrower than), closely mirroring the hierarchical architecture defined by Dublin Core terms22.

10. Conflict/Dispute Policy

Conflicts inevitably arise regarding semantic boundaries, especially in highly specialized, rapidly evolving, or culturally sensitive domains. When a Submitter and a Reviewer disagree, or when two Reviewers provide conflicting assessments regarding a mapping, the issue enters a formal disputed state. Competing semantic interpretations cannot coexist on a single ConceptCode, as this destroys the deterministic nature of the registry. During a dispute, the registry enforces a mandatory cooling-off and evidence-gathering period. The involved parties must submit structured counter-arguments mapped directly to the registry's strict evidence requirements. If consensus cannot be reached, the issue is escalated to a Designated Expert18. The Designated Expert evaluates the semantic conflict strictly on the principles of immutability and disambiguation. If the string is genuinely contested in the real world—meaning competing factions legitimately use the exact same expression to mean fundamentally different things—the registry must reflect that reality. It does so by refusing to map the ambiguous string to a single ConceptCode, instead marking the expression as unresolvable due to ambiguity, forcing downstream users to utilize more specific, distinct expressions to achieve resolution.

11. Appeal Process

The appeal process exists to challenge decisions made by Designated Experts, ensuring no single actor has unchecked, monopolistic authority over the semantic namespace. An appeal must be lodged within a specific, published timeframe following a rejection or a forced deprecation event. Appeals are heard by the Arbitration Board. To prevent frivolous or repeated appeals that drain administrative resources, the Submitter must provide entirely novel evidence that was not considered during the initial review, or they must explicitly demonstrate that the Designated Expert violated the documented governance policy during their ruling. The Arbitration Board's review process is entirely transparent; all deliberations and ultimate decisions are appended directly to the public transparency log. If the appeal is successful, a new transaction reversing the previous state is appended to the registry. The historical record of the initial decision, the dispute, and the final reversal remains permanently visible in the log, serving as precedent for future governance actions.

12. Merge Policy

A merge occurs when two distinct ConceptCodes are discovered to represent the exact same semantic identity. Because ConceptCodes may already be deeply embedded in downstream infrastructure and third-party databases, true database deletion of the redundant code is strictly prohibited10. Following the highly successful Wikidata model for merging entities, the registry selects a Recipient Concept, which is usually the older, more widely used, or lower-numbered ConceptCode24. All active expressions previously bound to the Obsolete Concept are meticulously re-bound to the Recipient Concept. The Obsolete Concept is then transitioned to a superseded state via an append-only log entry. A cryptographic pointer is permanently established from the Obsolete Concept to the Recipient Concept, effectively functioning as a semantic redirect24. Any downstream software querying the Obsolete Concept will receive a response indicating its superseded status, along with the correct Recipient ConceptCode, ensuring seamless backward compatibility.

13. Split Policy

Splits are structurally complex because they involve resolving historical ambiguity where a single code was incorrectly used for multiple concepts. A split occurs when a single ConceptCode is found to conflate two or more distinct meanings, often discovered as a domain matures. Under the Unicode and SNOMED CT stability doctrines, the original ConceptCode cannot simply change its definition to mean only one of the concepts, as this would invalidate all historical data that relied on the broader or alternative meaning previously associated with that code3. Therefore, the original ConceptCode must be transitioned to a deprecated state with a specific reason code indicating an ambiguous split. Two or more entirely new ConceptCodes are subsequently minted to represent the precise, newly disambiguated meanings. Expressions previously bound to the deprecated concept are meticulously reviewed and bound to the appropriate new ConceptCodes. Downstream systems querying the legacy ConceptCode will see that it has been split and must rely on contextual data to manually or algorithmically migrate their historical records to the new, specific codes.

14. Deprecation Policy

Deprecation is the primary mechanism for retiring semantic constructs without destroying historical integrity. Corrections differ fundamentally from deletions; a correction appends a new state indicating the previous state was flawed, whereas a deletion destroys the evidence of the flaw. Deletions are forbidden. A ConceptCode or Expression Binding may be deprecated if it is found to be mathematically erroneous, deeply ambiguous, or scientifically obsolete. Deprecation requires a formal review process that is just as rigorous as concept creation. The deprecation transaction must include an inactivation reason code, utilizing a standardized taxonomy similar to SNOMED CT's inactivation reasons21. Deprecated records are never removed from the registry schema or the active API endpoints. The API continues to serve deprecated ConceptCodes, ensuring that software processing decades-old datasets can still resolve the exact meaning of the embedded identities as they were understood at the time of authoring. The deprecation simply signals to modern clients that the ConceptCode should no longer be used for newly generated data.

15. Supersession Policy

Supersession is a specific, highly structured variant of deprecation where a clear evolutionary path exists between an older concept and a newer one. This mechanism is heavily utilized in medical terminology registries when scientific understanding evolves, requiring a conceptual upgrade rather than a simple retirement5. When Concept A is superseded by Concept B, Concept A is deactivated in the append-only log, and a strict replacement relationship is instantiated between the two codes. This creates a directed acyclic graph of semantic evolution. Governance policies dictate that the replacement concept must fully encompass the intended, historically understood meaning of the superseded concept, minimizing the risk of silent semantic breakage in downstream analytics. If the new concept is narrower, a split must occur instead of a direct supersession.

16. Registry Release/Version Model

To support offline infrastructure, air-gapped environments, and predictable synchronization for downstream consumers, the registry requires a robust, highly structured versioning model. How downstream systems discover changes is dictated by this release cycle. The framework adopts a dual-versioning approach combining Semantic Versioning for technical interfaces and calendar versioning for data payloads, heavily influenced by the SNOMED CT RF2 release model26.

Content releases are distributed in three distinct packages to optimize downstream consumption26:

1. Full Release: Contains the entire append-only history of the registry from its inception. Every state change of every ConceptCode is included5.

2. Snapshot Release: Contains only the most current active (and currently deprecated) state of every component as of the specific release date. This is ideal for systems that require operational resolution but do not need historical auditing.

3. Delta Release: Contains only the specific mutations that occurred between the previous calendar release date and the current release date, optimizing bandwidth for systems that synchronize frequently.

17. Backward-Compatibility Policy

In the context of semantic infrastructure, backward compatibility means that the interpretation of historical data must never be altered by registry updates. Semantic versioning applies strictly to the technical schema, but the semantic content is governed by a policy of perpetual non-interference6. A breaking semantic change is defined as any modification that fundamentally alters the extension or intension of an existing ConceptCode3. What should never be allowed to change after publication is the underlying meaning attached to a specific identifier. Examples of prohibited breaking changes include altering a concept's definition to encompass a broader or narrower scope than originally published, removing a ConceptCode from the registry entirely, or re-assigning a previously deprecated ConceptCode to a new meaning3. Non-breaking changes include adding new ConceptCodes, adding new expression bindings to existing concepts, or deprecating a concept. Deprecation is explicitly classified as a non-breaking change because it preserves the historical record and meaning, simply updating the recommended usage status. The registry must strictly enforce a zero-tolerance policy for breaking semantic changes to guarantee the decades-long durability of the infrastructure.

18. Audit Model

The registry must be fully and transparently auditable by third parties to maintain its status as trustworthy global infrastructure. The audit model relies on a strict separation between the operational database that serves queries and an independent, cryptographic verification layer that stores the history of changes. All mutations must be deterministically serialized and cryptographically hashed before being written. Independent auditors can reconstruct the entire current state of the registry at any given point in time by replaying the append-only log from the genesis block forward. Regular external audits should focus not only on cryptographic integrity—ensuring hashes align—but also on process compliance. Auditors must verify that the Review-State Machine was strictly followed, that Multilingual Review Policies were enforced by appropriately credentialed personnel, and that the specified evidence thresholds were met for all active concepts.

19. Transparency-Log Options

To completely secure the append-only nature of the registry and prevent internal tampering, it must integrate with a cryptographic transparency log system. History must be cryptographically chained. The Sigstore/Rekor architecture provides an optimal template for this implementation4. Every transaction—whether it is a Concept creation, an expression binding, or a deprecation—generates a structured payload containing the mutation data, the provenance metadata, and the Submitter and Reviewer signatures. This payload is submitted to a decentralized or highly replicated transparency log, such as Rekor4. The transparency log hashes the transaction into a Merkle tree and returns a cryptographic inclusion proof, often formatted as a Signed Certificate Timestamp. This inclusion proof is subsequently embedded directly into the registry's release files. This mechanism guarantees that the registry administrators cannot silently alter historical records, as any modification to a past event would break the Merkle tree root of the transparency log, instantly and publicly alerting the entire ecosystem to the tampering attempt.

20. Cryptographic Attestation Options

In addition to transparency logging for the data payloads, the registry must utilize cryptographic attestation to bind specific governance actions to verified human identities. Utilizing OpenID Connect (OIDC) combined with ephemeral, short-lived certificates—the core of the Sigstore model—minimizes the catastrophic risks associated with long-term cryptographic key management and compromise15. When a Reviewer approves a semantic mapping, they authenticate via an established OIDC provider. An ephemeral certificate is generated, valid only for the brief duration of the signing event. The Reviewer uses this temporary key to sign the transaction payload, and the signature, along with the certificate containing the OIDC identity claim, is committed to the registry. Downstream consumers can independently verify that a specific domain expert, tied to a verifiable organizational identity at the exact moment of the transaction, authorized the semantic binding.

21. Trust Tiers

Not all semantic identities require the same level of rigorous, time-consuming governance. Attempting to force local jargon through international arbitration creates governance paralysis. Therefore, the registry should implement explicit Trust Tiers to balance operational agility with infrastructural stability.

By separating concepts into strict namespaces, the registry prevents experimental or localized terminology from polluting the core semantic resolution engine, while simultaneously providing a structured pathway for localized terms to be promoted to higher tiers if they gain broader global adoption.

22. Federation Governance

To prevent a centralized bottleneck and reduce single points of failure, the registry architecture must support federation from inception. Federation allows independent organizations, consortia, or sovereign governments to host their own registries while seamlessly interoperating with the global semantic network. Federation governance dictates that the global root registry maintains absolute authoritative control over the Core namespaces. However, federated nodes may act as the sole authoritative sources for specific, delegated domain namespaces. For example, a medical university could run a federated node that is exclusively authoritative for a highly specific medical sub-domain namespace. Federated registries must strictly adhere to the same API schema, transparency log requirements, and append-only lifecycle rules as the root node. Cross-registry resolution relies entirely on the namespaces; an expression resolving to a federated ConceptCode explicitly informs the downstream consumer of the authoritative source, allowing the consuming application to apply its own customized trust weighting based on the origin of the data.

23. Enterprise/Private-Registry Considerations

Enterprises frequently require the ability to run entirely private instances of the Embedded Semantics registry to govern highly classified, proprietary, or compliance-restricted semantic identities. A private enterprise registry utilizes the exact same open-source software stack and governance schema as the public node, but operates within an air-gapped or heavily access-controlled corporate network. For interoperability, private registries are typically configured to synchronize down from the global public registry—consuming public ConceptCodes for use in internal analytics—but they are restricted from synchronizing proprietary ConceptCodes upward to the public network. The governance model in a private setting allows the enterprise to replace global public OIDC providers with internal identity providers, such as Active Directory, to manage Submitter and Reviewer roles. This maintains internal cryptographic attestation and auditability for regulatory compliance purposes without exposing proprietary workflows to the outside world.

24. Abuse and Capture Risks

A high-trust registry inevitably becomes a prime target for semantic capture, where malicious, commercial, or ideologically motivated actors attempt to redefine terms, squat on valuable namespace prefixes, or flood the system with ambiguous expressions to degrade its utility. The primary risk is semantic hijacking, where an actor attempts to alter a ConceptCode's meaning to benefit a specific entity or viewpoint. The strict immutability principle and append-only log mitigate this entirely; hijacking requires an overt, easily audited transaction that creates a new record, which can be quickly detected, appealed, and deterministically reversed by the Arbitration Board3. Flooding or squatting—submitting millions of spurious mappings to exhaust reviewer capacity—is mitigated through the implementation of algorithmic rate limits, required trust levels and identity verification for Submitters, and the inherent friction of the mandatory Reviewer validation process. Finally, regulatory capture, where a coordinated group of Reviewers attempts to take over a domain namespace to enforce a specific worldview, is countered by the Arbitration Board acting as an independent check. Furthermore, the federated namespace model allows the broader community to cleanly fork a namespace if the root governance becomes terminally compromised.

25. Example Governance Records

To illustrate the JSON representation of an append-only transaction utilizing cryptographic provenance, the following schema demonstrates an expression binding event. This structure strictly separates the payload from the provenance, ensuring the semantic binding can be instantly evaluated by parsers while the cryptographic evidence remains intact for deep auditing14.

JSON { "transaction\_id": "tx\_8f9c2a1b9d4e...", "timestamp": "2026-08-23T11:22:32Z", "action": "BIND\_EXPRESSION", "target\_concept": "core:C\_10485", "payload": { "expression": "quantum entanglement", "language": "en", "dialect": "US", "evidence\_uris": \["https://doi.org/10.1103/PhysRev.47.777"\] }, "provenance": { "submitter\_id": "oidc:sub:user123\_verified", "reviewer\_id": "oidc:sub:expert456\_physics\_board", "policy\_version": "1.4.0", "transparency\_log\_inclusion": "sct\_99a8b7c6d5...", "reviewer\_signature": "sig\_a1b2c3d4..." } }

26. Example Concept Change History

The following table simulates the append-only history of a single ConceptCode undergoing creation, an expression binding, and eventual supersession due to a split in scientific understanding. Note that no row is ever deleted; the state is simply updated in subsequent, timestamped transactions, precisely mirroring the SNOMED CT RF2 methodology5.

27. Recommended Minimum Viable Governance System

To prevent governance paralysis during the initial bootstrapping phase of the Embedded Semantics Concept Registry, a Minimum Viable Governance (MVG) model should be deployed first, focusing on architectural non-negotiables rather than bureaucratic overhead. The initial deployment should be centralized but transparent. The registry begins with a centralized Registrar operated by the founding organization. All actions are meticulously logged, but complex cryptographic attestation is initially handled via standard API keys rather than ephemeral OIDC certificates, lowering the barrier to entry for early contributors. The system should implement basic role separation, utilizing only Submitter and Reviewer roles, deferring the creation of the formal Arbitration Board until transaction volume and dispute frequency warrant it. Crucially, strict append-only enforcement must be implemented on day one. The RF2-style active and effectiveTime log is an architectural prerequisite that cannot be easily retrofitted into a legacy database that allows destructive deletes5. Finally, the MVG must strictly enforce immutable concepts; definitions cannot change. If a mistake is made during bootstrapping, users are forced to practice the Deprecation and Supersession workflows, establishing the cultural norm of immutability early.

28. Advanced Governance Roadmap

As the registry matures into critical internet infrastructure, relied upon by international supply chains and archival systems, the governance model must evolve to distribute trust and eliminate single points of failure. In the initial phase, spanning the first year, the focus remains on implementing the MVG, building the core semantic dataset, and establishing the baseline transparency log integration. The second phase introduces full cryptographic attestation using the Sigstore model, eliminating API keys in favor of OIDC identity bindings4. During this phase, the Federation protocol is finalized, allowing trusted external partners to host and govern their own domain namespaces. The formal Arbitration Board is also seated. The final phase represents the complete decentralization of the Core namespace governance. The role of the Registrar transitions from a single founding organization to an international consortium, similar in structure to the W3C or the Unicode Consortium, governed by a multi-stakeholder charter that ensures perpetual neutrality and funding28.

29. Decision Matrix

The following matrix summarizes the critical architectural decisions embedded in this specification, mapping them directly to the prior art and justifications derived from existing high-trust global systems.

By adopting these proven, battle-tested mechanisms, the Embedded Semantics Concept Registry will achieve the necessary durability, trust, and operational resilience to serve as foundational semantic infrastructure for decades to come, unaffected by the shifting tides of probabilistic language models.

Works cited

1. https://embeddedsemantics.com/

2. A Study of the Framework and Real-World Applications of Language Embedding for 3D Scene Understanding \- arXiv, https://arxiv.org/html/2508.05064v2

3. Unicode® Character Encoding Stability Policies, https://www.unicode.org/policies/stability\_policy.html

4. Securing Your Container Supply Chain: A Practical Guide to, https://think-ahead.tech/en/blog/container-signing

5. History Mechanism | Specifications SNOMED CT Release File Specification, https://docs.snomed.org/snomed-ct-specifications/snomed-ct-release-file-specification/release-types-packages-and-files/3.1-common-features-of-all-release-files/3.1.5-history-mechanism

6. Introduction to Web Architecture \- W3C, https://www.w3.org/2001/tag/2002/0607-intro

7. GTIN Reuse Policy Update \- GTIN INFO Global Trade Item Number, https://www.gtin.info/gtin-reuse-policy-update/

8. Lol, few things trigger my OCD more than misspelled words in identifiers. I legi... | Hacker News, https://news.ycombinator.com/item?id=28323515

9. L2/06-106 \- Unicode, https://www.unicode.org/L2/L2006/06106-stability.pdf

10. CoreStructure RF2 | PDF | Concept \- Scribd, https://www.scribd.com/document/1044174214/CoreStructure-RF2

11. GTIN non-reuse \- GS1, https://www.gs1.org/1/hcgtinrules/en/gtin-non-reuse

12. GTIN Management Rules \- GS1 Sweden, https://gs1.se/en/identify/global-trade-item-number-gtin/gtin-management-rules/

13. Can a GTIN be reused? \- GS1 GO Customer Service Portal, https://support.gs1.org/support/solutions/articles/43000734390-can-a-gtin-be-reused-

14. Metadata registry \- Wikipedia, https://en.wikipedia.org/wiki/Metadata\_registry

15. Image Signing with Sigstore: Keyless Authentication and, https://www.cleanstart.com/knowledge-hub/image-signing-sigstore

16. Pluggable Types \- Sigstore, https://docs.sigstore.dev/logging/pluggable-types/

17. Help \- Metadata Registry, https://dss.aristotlecloud.io/help/

18. Specification Required Sub-Policies, https://ftp.sjtu.edu.cn/pub/internet-drafts/draft-nottingham-ianabis-spec-reqd-02.html

19. SPDX Cryptographic Algorithm List release policy · Issue \#52 \- GitHub, https://github.com/spdx/cryptographic-algorithm-list/issues/52

20. SNOMED International Release Management \- SNOMED Spaces, https://conf.spaces.snomed.org/wiki/spaces/RMT/pages/131989968/SNOMED+CT+Managed+Service+-+US+Edition+SNOMED+CT+to+ICD-10-CM+Release+Notes+-+March+2025

21. SNOMED CT's RF2: Is the Future Bright? \- PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC3379709/

22. DCMI Metadata Terms \- Dublin Core Metadata Initiative, https://www.dublincore.org/specifications/dublin-core/dcmi-terms/2008-01-14/

23. Literature review of SNOMED CT use | Request PDF \- ResearchGate, https://www.researchgate.net/publication/245538092\_Literature\_review\_of\_SNOMED\_CT\_use

24. Help:Merge \- Wikidata, https://www.wikidata.org/wiki/Help:Merge/en

25. Wikidata:Requests for comment/Redirect vs. deletion, https://www.wikidata.org/wiki/Wikidata:Requests\_for\_comment/Redirect\_vs.\_deletion

26. SNOMED CT Archives \- National Library of Medicine, https://www.nlm.nih.gov/healthit/snomedct/archive.html

27. 7 SPDX and Software Bill of Materials ISO/IEC 5962L 2021 \- Oxford Academic, https://academic.oup.com/book/44727/chapter/378966287

28. UAX \#44: Unicode Character Database, http://www.unicode.org/reports/tr44/tr44-22.html

29. Version Management in W3C Technical Reports, https://www.w3.org/guide/editor/versioning.html