# VII. ONTOLOGIES

## 7.1 Ontology Commons Doctrine

### 7.1.1 Ontology object defined.

An **Ontology Object** under DDPGF means any governed digital-public-good object that defines, structures, relates, constrains, maps, or interprets concepts, terms, classes, entities, relationships, attributes, statuses, labels, categories, evidence types, risk meanings, workflow states, readiness states, data-use labels, AI-use labels, public-safe statuses, safeguard categories, public authority boundary categories, finance and insurance boundary categories, handoff dependency categories, or other semantic elements used within the Nexus Ecosystem. An Ontology Object may include controlled vocabularies, taxonomies, classification systems, data dictionaries, schema definitions, entity models, relationship models, crosswalks, mappings, code lists, reference tables, knowledge graph structures, interoperability profiles, semantic version records, translation records, localization records, deprecation records, and correction records.

An Ontology Object shall be treated as public-good semantic infrastructure. It shall make Nexus objects more legible, interoperable, searchable, comparable within scope, reviewable, reusable, localizable, and correctionable. It shall not create legal classification, regulatory classification, certification, public authority determination, procurement status, financeability, insurability, community consent, Indigenous consent, deployment authorization, or execution authority by implication. Its authority shall remain limited to its recorded scope, steward, version, evidence basis, review status, access class, localization status, and boundary notices.

### 7.1.2 Controlled vocabulary defined.

A **Controlled Vocabulary** means a governed set of approved terms, preferred labels, alternate labels, definitions, usage notes, prohibited usage notes, scope notes, translation notes, localization notes, relationship notes, and correction history used to ensure consistent meaning across Nexus records, Reports, Dockets, Registry entries, Marketplace listings, Studio workflows, Grid inputs, TRL notes, DICE records, GRIx categories, DRI indicators, Observatory signals, National Portfolio records, Nexus Universe outputs, Academy learning objects, Foundry objects, Campaign objects, Proof Receipts, and lawful handoff packages.

A Controlled Vocabulary shall reduce semantic ambiguity, prevent overclaim, support multilingual and jurisdiction-sensitive use, and preserve role separation. It shall not be used to convert a public-good term into a legal status unless separately adopted by competent authority. Where a term carries legal, regulatory, financial, insurance, procurement, public authority, community, Indigenous, health, cyber, infrastructure, or safety-sensitive meaning, the vocabulary shall include boundary language preventing unauthorized reliance, equivalence, or authority by implication.

### 7.1.3 Schema object defined.

A **Schema Object** means a governed structure that defines the required, optional, conditional, and prohibited fields, formats, data types, relationships, validation rules, labels, metadata elements, access classes, review statuses, lifecycle states, versioning rules, public-safe fields, sensitivity fields, correction fields, and archive fields for a digital-public-good object. Schema Objects may govern datasets, APIs, evidence packs, model cards, system cards, benchmark cards, agent workflow cards, reports, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL evidence notes, credentials, learning records, Proof Receipts, Dockets, Support Ledgers, Assumptions Registers, Dependency Registers, Diligence-Gap Registers, Correction Registers, Archive Registers, National Portfolio objects, Nexus Universe records, and handoff packages.

A Schema Object shall support interoperability, quality, traceability, validation, portability, and correction. It shall not certify the quality, truth, legality, safety, completeness, financeability, insurability, procurement readiness, public authority approval, or deployment readiness of the object that conforms to it. Schema conformance shall mean only that the object follows the recorded structure within scope, not that the object has been substantively approved.

### 7.1.4 Taxonomy object defined.

A **Taxonomy Object** means a governed hierarchical or faceted classification structure used to organize domains, risks, hazards, technologies, systems, sectors, outputs, evidence classes, data classes, model classes, workflow classes, participant classes, readiness classes, safeguard classes, public authority boundary classes, finance and insurance boundary classes, handoff dependency classes, or other Nexus categories. A Taxonomy Object may be single-hierarchy, multi-hierarchy, graph-linked, jurisdiction-localized, language-localized, or crosswalked to external taxonomies.

A Taxonomy Object shall help organize meaning, routing, discovery, reporting, Docketing, learning, review, Registry status, Marketplace listing, Grid review, TRL evidence, Observatory signals, DRI indicators, and handoff dependency notes. It shall not impose legal classification, country ranking, risk rating, provider validation, procurement qualification, finance signal, insurance signal, community consent, public warning, or regulatory determination by implication.

### 7.1.5 Knowledge graph object defined.

A **Knowledge Graph Object** means a governed representation of entities, relationships, attributes, provenance, confidence, uncertainty, sensitivity, access classes, source links, object links, dependency links, version links, correction links, and lifecycle states across Nexus digital-public-good objects. A Knowledge Graph Object may connect people, institutions, systems, datasets, models, reports, risks, hazards, technologies, places, workflows, indicators, records, Dockets, Registry entries, Marketplace listings, Studio workflows, Grid inputs, TRL notes, National Portfolio objects, Nexus Universe outputs, and lawful handoff dependencies.

A Knowledge Graph Object shall be designed for public-good sensemaking, discovery, interoperability, systems-risk understanding, evidence traceability, correction propagation, and institutional memory. It shall not be designed or used as unauthorized surveillance, social scoring, hidden profiling, public authority decision-making, financial scoring, insurance scoring, procurement scoring, employment screening, consent inference, community ranking, Indigenous knowledge extraction, or operational command. Knowledge graph use shall be subject to data minimization, access control, sensitivity review, protected knowledge controls, public-safe views, controlled views, correction, and archive.

### 7.1.6 Semantic interoperability as public-good infrastructure.

Semantic interoperability shall be a core DDPGF public-good function. It shall allow digital objects created across different Nexus pillars, mechanisms, institutions, countries, sectors, languages, technologies, repositories, platforms, and lawful handoff pathways to be understood, mapped, exchanged, reviewed, reused, translated, localized, routed, corrected, and archived without collapsing their meaning or authority. Semantic interoperability shall connect software, data, models, APIs, dashboards, digital twins, simulations, notebooks, learning objects, credentials, reports, campaigns, Registry records, Marketplace listings, Studio workflows, Grid records, TRL notes, Proof Receipts, National Portfolio objects, Nexus Universe outputs, Observatory signals, DRI indicators, GRIx categories, DICE records, and handoff packages.

Semantic interoperability shall not require semantic uniformity. It shall preserve local meaning, legal context, national terminology, language context, community context, Indigenous protocol-sensitive meaning where applicable, public authority boundaries, finance and insurance boundaries, and protected knowledge restrictions. Interoperability shall be achieved through explicit mapping, versioning, localization notes, translation notes, scope notes, confidence labels, provenance records, and correction pathways, not through silent equivalence.

### 7.1.7 GRIx as risk meaning layer.

**GRIx** shall serve as the Nexus risk meaning layer for structuring risk categories, systems-risk relationships, all-hazards language, WFEH-B relationships, DRR, DRF, and DRI terminology, exponential technology risk categories, public authority boundary categories, finance and insurance boundary categories, safeguard categories, handoff dependency categories, and public-safe reporting language. GRIx shall support consistent risk interpretation across DICE, DRI, Nexus Observatory, Nexus Studio, Nexus Grid, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Universe, Nexus Foundry, Nexus Campaigns, Nexus Academy, Risk Academy, Risk Agency, National Portfolios, National Working Groups, Competence Cells, and lawful handoff packages.

GRIx shall be a controlled semantic layer, not a legal authority, rating system, public warning system, insurance scoring system, investment scoring system, procurement classification system, compliance certification system, public authority decision system, or deployment authorization system. GRIx categories shall provide meaning, routing, and structured interpretation within scope, while preserving uncertainty, jurisdictional limits, source limits, public-safe limits, and correctionability.

### 7.1.8 Ontology without legal classification by implication.

No Ontology Object, Controlled Vocabulary, Schema Object, Taxonomy Object, Knowledge Graph Object, GRIx category, DRI mapping, Registry field, Marketplace label, Studio tag, Grid label, TRL field, Report category, National Portfolio category, Nexus Universe label, or handoff dependency label shall create legal classification by implication. Legal classification, regulatory status, public authority determination, official warning status, procurement status, financeability, insurability, certification, professional status, community consent, Indigenous consent, deployment authorization, or execution authority shall require separate lawful basis by competent actors outside the default DDPGF ontology layer.

Semantic precision shall strengthen trust by making claims narrower, not broader. Where a term may be confused with a legal or official status, the ontology shall include boundary notes, prohibited-use notes, and public-safe wording requirements.

## 7.2 GRIx Object Classes

### 7.2.1 Risk categories.

GRIx Risk Categories shall structure the terms and relationships used to identify, describe, compare within scope, route, review, communicate, and correct risk-related information across Nexus. Risk categories may include hazard categories, exposure categories, vulnerability categories, resilience-capacity categories, uncertainty categories, confidence categories, cascading-risk categories, systemic-risk categories, operational-risk categories, technology-risk categories, institutional-risk categories, social-risk categories, environmental-risk categories, data-risk categories, AI-risk categories, cyber-risk categories, privacy-risk categories, safeguard-risk categories, public-safe publication-risk categories, and handoff-risk categories.

Risk Categories shall support analysis, learning, public-safe reporting, DRI indicator logic, Observatory signal interpretation, Studio scenarios, Grid review, TRL evidence notes, Reports, National Portfolios, and lawful handoff dependency mapping. They shall not constitute ratings, warnings, regulatory determinations, compliance findings, insurance scores, investment signals, procurement rankings, or country rankings.

### 7.2.2 WFEH-B categories.

GRIx WFEH-B Categories shall structure water, food, energy, health, biodiversity, and nature-related systems, dependencies, stresses, vulnerabilities, resilience capacities, indicators, interventions, infrastructure linkages, supply-chain linkages, data objects, model objects, digital twin objects, scenario objects, and public-safe reporting language. These categories shall support cross-system analysis, cascading-risk interpretation, national portfolio formation, Nexus Universe arenas, DRI records, Observatory records, Foundry builds, Academy learning objects, Reports, Studio workflows, Grid inputs, TRL notes, and handoff dependency notes.

WFEH-B Categories shall not create environmental certification, public health determination, biodiversity approval, water-right determination, energy approval, food-system certification, green claim validation, public authority decision, procurement preference, financeability, insurability, or community consent by implication. Sensitive ecological, health, geospatial, community, and protected knowledge categories shall require public-safe and protected knowledge controls.

### 7.2.3 DRR categories.

GRIx Disaster Risk Reduction Categories shall structure hazards, exposure, vulnerability, preparedness, prevention, mitigation, response learning, recovery learning, resilience capacity, early-warning relevance, public authority dependencies, humanitarian sensitivity, community resilience, infrastructure resilience, and systems-risk relationships. DRR Categories shall support alignment with public-safe disaster-risk language, DRI indicator design, Observatory signal review, Studio scenarios, Reports, National Portfolios, Nexus Universe arenas, and lawful handoff dependency packages.

DRR Categories shall not make NAF, DDPGF, Nexus, GCRI, The Global Risks Forum (GRF), or The Global Risks Alliance (GRA) a public warning authority, emergency command actor, regulator, public authority, or humanitarian command body. DRR semantic classification shall remain learning, evidence, routing, and public-safe reporting infrastructure.

### 7.2.4 DRF categories.

GRIx Disaster Risk Finance Categories shall structure risk-layering concepts, protection-gap concepts, insurance-readiness questions, public finance relevance questions, donor-readiness questions, contingent finance concepts, resilience investment context, loss-and-damage context, claims discipline, no-reliance labels, diligence-gap labels, finance boundary labels, and handoff dependency notes. DRF Categories shall help translate risk evidence into capital-readable, insurance-readable, donor-readable, and public finance-readable questions without converting evidence into finance.

DRF Categories shall not constitute financial advice, insurance advice, underwriting, brokering, investment advice, credit assessment, donor commitment, guarantee commitment, public finance allocation, bankability, financeability, insurability, or transaction readiness by implication. They shall preserve regulated-perimeter discipline and no-reliance controls.

### 7.2.5 DRI categories.

GRIx Disaster Risk Intelligence Categories shall structure indicators, signals, hotspot logic, cascade logic, confidence labels, uncertainty labels, data source classes, dashboard classes, public-safe intelligence summaries, correction status, archive status, and national contribution records. DRI Categories shall help produce structured risk intelligence for learning, public-safe reporting, Observatory integration, Studio workflows, National Portfolios, Nexus Universe, Reports, Registry, Marketplace, Grid, TRL, and handoff context.

DRI Categories shall not create public warnings, official forecasts, country rankings, insurance scores, investment signals, procurement signals, emergency command, surveillance authority, or public authority decisions. DRI outputs shall remain bounded, public-safe, correctionable, and non-executing.

### 7.2.6 Exponential technology categories.

GRIx Exponential Technology Categories shall structure technology domains, including AI, agentic systems, AI-RAN, O-RAN, telecommunications, private wireless, edge systems, cloud, HPC, sovereign compute, verifiable compute, cybersecurity, OT, IoT, IIoT, sensors, geospatial systems, Earth observation, digital twins, drones, robotics, DLT, DePIN, Web3, digital identity, quantum-relevant security, semiconductors, advanced manufacturing, biosecurity-sensitive systems, health-relevant innovation, frontier science infrastructure, and related digital-public-good objects.

These categories shall support R\&D routing, Foundry builds, data governance, AI governance, software governance, protocol mapping, standards-interface records, Studio workflows, Grid review, TRL notes, Marketplace discovery, Registry status, Reports, National Portfolios, Nexus Universe arenas, and lawful handoff. They shall not create technology certification, standards conformance, export-control clearance, safety approval, deployment authorization, procurement preference, provider validation, financeability, insurability, or public authority approval by implication.

### 7.2.7 Public authority boundary categories.

GRIx Public Authority Boundary Categories shall structure records that distinguish learning, observation, evidence, public-safe reporting, standards-interface work, policy intelligence, public authority participation, public authority dependency, public authority approval outside Nexus, official action outside Nexus, permits, licenses, emergency command, public warnings, public finance, regulatory decisions, and other official-government or public-authority functions. These categories shall prevent role collapse between Nexus public-good work and public authority action.

Public authority boundary categories shall be mandatory where DDPGF objects may be misread as official, regulatory, governmental, emergency, permitting, licensing, compliance, inspection, public finance, or public warning outputs. Such categories shall clarify that public authority participation, public authority learning rooms, public authority data interfaces, Reports, dashboards, Studio workflows, Registry records, Marketplace listings, Grid inputs, TRL notes, and handoff packages do not create official action unless separately and lawfully recorded by competent public authority.

### 7.2.8 Finance and insurance boundary categories.

GRIx Finance and Insurance Boundary Categories shall structure capital-readability, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, diligence gaps, assumptions, dependencies, no-reliance status, non-solicitation status, non-transactional status, risk-to-capital translation, protection-gap language, and handoff finance dependencies. These categories shall help DDPGF objects remain readable to capital, insurance, donor, and public finance actors without entering regulated activities or implying transaction readiness.

Finance and insurance boundary categories shall prohibit overclaim. They shall not constitute financial advice, investment recommendation, underwriting, insurance approval, public finance allocation, donor commitment, guarantee approval, bankability, financeability, insurability, securities offering, solicitation, brokerage, or transaction execution.

### 7.2.9 Safeguard categories.

GRIx Safeguard Categories shall structure community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, privacy sensitivity, health sensitivity, gender and equity concerns, non-extractive engagement, community-facing correction, data sovereignty, sensitive location controls, rights-bearing data, and public-safe publication controls. These categories shall support review gates across DICE, Reports, Studio, Marketplace, Registry, Grid, TRL, Foundry, Campaigns, Academy, Nexus Universe, National Portfolios, and lawful handoff.

Safeguard categories shall not imply that safeguard review has granted consent, approval, certification, ethical clearance, public authority approval, community authorization, Indigenous consent, or legal compliance by default. Safeguard categories identify obligations, risks, limits, and review needs.

### 7.2.10 Handoff dependency categories.

GRIx Handoff Dependency Categories shall structure the conditions, unresolved questions, recipient responsibilities, public authority dependencies, legal dependencies, technical dependencies, data dependencies, AI dependencies, cyber dependencies, privacy dependencies, safeguard dependencies, provider-neutrality notes, sponsor-boundary notes, finance-readiness questions, insurance-readiness questions, procurement boundaries, support needs, correction pathways, recall pathways, and archive rules associated with lawful handoff packages.

Handoff dependency categories shall reinforce that handoff transfers context and dependencies, not authority. They shall not authorize execution, deployment, procurement, finance, insurance, public authority action, community consent, Indigenous consent, provider selection, operator approval, or recipient reliance without separate lawful basis.

## 7.3 Schema Object Classes

### 7.3.1 Data schemas.

Data Schemas shall define the structure, fields, types, relationships, data-use labels, AI-use labels, quality fields, lineage fields, rights fields, sensitivity fields, public-safe fields, access fields, retention fields, correction fields, and archive fields for data objects governed under DDPGF. Data Schemas shall support data quality, interoperability, DICE routing, Registry records, Marketplace listings, Studio workflows, Reports, DRI indicators, Observatory records, Grid inputs, TRL evidence notes, National Portfolios, and handoff packages.

A Data Schema shall not create data rights, open-data status, privacy compliance, public authority status, unrestricted reuse permission, AI-training permission, or handoff permission by implication.

### 7.3.2 Metadata schemas.

Metadata Schemas shall define the common descriptive, administrative, technical, rights, provenance, sensitivity, review, support, public-safe, correction, and archive fields used across DDPGF objects. Metadata Schemas shall support search, discovery, versioning, reuse, citation, repository deposits, Marketplace listings, Registry records, Reports, and institutional memory.

Metadata may be public where the underlying object is controlled, restricted, secure-room-only, or archive-only. Metadata visibility shall not make the underlying object open, accessible, reusable, AI-trainable, publishable, deployable, or handoff-ready.

### 7.3.3 API schemas.

API Schemas shall define endpoint structures, request and response fields, authentication requirements, authorization rules, rate limits, error formats, versioning, deprecation rules, data minimization, public-safe filtering, logging, abuse controls, and correction pathways for APIs and connectors. API Schemas shall support interoperability among DICE, Registry, Marketplace, Studio, Reports, Campaigns, Academy, DRI, Observatory, Grid, National Portfolios, and lawful handoff systems.

API Schema conformity shall not create data rights, unrestricted access, provider validation, security certification, standards conformance certification, public authority approval, or deployment authorization.

### 7.3.4 Evidence schemas.

Evidence Schemas shall define the required structure for evidence packs, method notes, review records, evaluation records, benchmark records, model cards, system cards, data provenance records, software evidence records, DRI records, Observatory records, Studio records, Grid inputs, TRL notes, and handoff evidence context. Evidence Schemas shall require scope, source, method, assumptions, limitations, uncertainty, confidence, review status, public-safe status, safeguard status, correction pathway, and archive rule where applicable.

Evidence Schema conformity shall not make evidence sufficient for certification, public authority approval, financeability, insurability, procurement readiness, deployment authorization, or execution. Substantive review remains separate.

### 7.3.5 Report schemas.

Report Schemas shall define the structure for Nexus Reports, including title, purpose, scope, source basis, evidence basis, methods, limitations, public-safe abstract, data availability statement, AI-use statement, license, citation, related identifiers, correction pathway, withdrawal pathway, no-conversion notice, archive rule, and routing to Registry, Marketplace, Studio, Grid, TRL, National Portfolios, Nexus Universe, or handoff context.

Report Schema conformity shall not convert publication into authority, public warning, official decision, financeability, procurement readiness, certification, country ranking, or deployment authorization.

### 7.3.6 Registry schemas.

Registry Schemas shall define the fields and validation rules used to preserve status truth, versioning, support status, review status, lifecycle state, provenance, correction history, withdrawal history, recall history, archive status, access class, public-safe status, boundary notices, and object relationships. Registry Schemas shall support correction propagation and institutional memory.

A Registry Schema shall not make a Registry record a certification, approval, legal status, procurement status, finance signal, public authority status, or deployment status. The Registry records status truth within scope; it does not create universal validation.

### 7.3.7 Marketplace schemas.

Marketplace Schemas shall define the structure for discovery listings, including object identity, description, steward, version, license, access class, support class, review status, Registry link, public-safe status, use limitations, boundary notices, correction pathway, and delisting rule. Marketplace Schemas shall support public-good discovery, support discovery, learning discovery, contribution discovery, and handoff awareness.

Marketplace Schema conformity shall not create endorsement, procurement recommendation, provider validation, financeability, insurability, deployment authorization, or execution authority.

### 7.3.8 Studio workflow schemas.

Studio Workflow Schemas shall define the structure of controlled runtime workflows, including purpose, users, models, data, tools, access controls, no-command rules, no-write-back rules, output review, logging, sensitivity class, public-safe controls, shutdown triggers, correction triggers, and archive rules. Studio Workflow Schemas shall support simulations, digital twins, dashboards, AI workflows, secure-room workflows, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, Nexus Universe demonstrations, and handoff demonstrations.

Studio Workflow Schema conformity shall not authorize deployment, public authority action, finance approval, insurance underwriting, operational command, or execution.

### 7.3.9 Grid schemas.

Grid Schemas shall define readiness, review-routing, evidence sufficiency, support status, correction status, and maturity-input fields for objects reviewed through Nexus Grid. They shall structure evidence quality, method quality, data status, AI-use status, cyber status, public-safe status, safeguard status, support status, repository status, Marketplace status, Registry status, and handoff dependency status.

Grid Schema conformity shall not create maturity certification, technical certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution authority.

### 7.3.10 TRL evidence schemas.

TRL Evidence Schemas shall define how TRL 1–10 evidence notes are recorded, including object identity, technology scope, evidence basis, environment, validation method, limitations, support status, public-safe status, safeguard status, dependencies, review status, correction pathway, and archive rule. TRL Evidence Schemas shall distinguish technical readiness context from certification or deployment authorization.

TRL Evidence Schema conformity shall not make an object procurement-ready, financeable, insurable, public authority-approved, deployment-authorized, or execution-ready.

### 7.3.11 Credential schemas.

Credential Schemas shall define the structure of micro-credentials, badges, learning records, skill wallet records, ILA entries, WILP records, competency evidence records, reviewer records, mentor records, and contribution records. They shall include issuer identity, evidence basis, competency mapping, review status, expiry, renewal, suspension, withdrawal, privacy controls, display class, correction pathway, and boundary notices.

Credential Schema conformity shall not create a degree, professional license, employment qualification, immigration status, procurement qualification, public authority approval, deployment authorization, or community consent.

### 7.3.12 Proof receipt schemas.

Proof Receipt Schemas shall define the fields used to record that a specific object, contribution, review, release, correction, learning action, support action, Docket movement, Registry update, Marketplace listing, Studio workflow, Grid input, TRL note, Report publication, Nexus Universe output, or handoff package occurred within a defined scope and time. Proof Receipt Schemas may include identifier, object link, actor class, date, action type, scope, evidence reference, limitations, boundary notice, correction pathway, and archive rule.

A Proof Receipt shall prove that a recordable event occurred within scope; it shall not prove certification, approval, consent, financeability, insurability, procurement readiness, deployment authorization, or execution authority.

## 7.4 Semantic Governance

### 7.4.1 Term proposal.

Term proposal shall be the process by which a new term, definition, category, schema element, relationship, label, status, or mapping is submitted for inclusion in an Ontology Object, Controlled Vocabulary, Taxonomy Object, Schema Object, GRIx object, or Knowledge Graph Object. A term proposal shall include purpose, scope, source basis, proposed definition, related terms, prohibited meanings, boundary risks, jurisdictional sensitivity, language or translation issues, data or AI implications, public-safe implications, safeguard implications, and correction pathway.

Term proposals shall be routed to appropriate stewards, reviewers, domain experts, public-safe reviewers, safeguard reviewers, and institutional interfaces where needed. A proposed term shall not become authoritative by use alone.

### 7.4.2 Term review.

Term review shall assess clarity, necessity, interoperability, evidence basis, overlap, ambiguity, legal sensitivity, public authority sensitivity, finance or insurance sensitivity, procurement sensitivity, safeguard sensitivity, protected knowledge sensitivity, translation risk, localization risk, public-safe risk, and overclaim risk. Term review shall determine whether the term should be approved, revised, merged, mapped, restricted, deprecated, rejected, or held for further evidence.

Term review shall be recorded. Review shall not create legal classification, certification, public authority approval, or standards authority.

### 7.4.3 Definition approval within scope.

Definition approval shall approve a term only within its recorded scope, version, stewarding context, language, and use case. A definition may be approved for internal DDPGF use, public-safe reporting use, Registry use, Marketplace use, Studio use, Grid use, TRL use, DRI use, GRIx use, DICE use, Academy use, National Portfolio use, Nexus Universe use, or handoff context use. Approval in one context shall not automatically approve use in all contexts.

Definition approval shall include scope notes, usage notes, prohibited-use notes, boundary notes, localization notes, translation notes, and correction pathway. Where a term may be confused with official, legal, financial, insurance, procurement, certification, or public authority meaning, the definition shall include no-conversion language.

### 7.4.4 Versioning.

Ontology Objects, Controlled Vocabularies, Schema Objects, Taxonomy Objects, GRIx objects, and Knowledge Graph Objects shall be versioned. Version records shall identify changes, additions, removals, deprecations, mapping changes, definition changes, localization changes, translation changes, correction actions, effective date, steward, review status, and downstream impacts. Versioning shall preserve backward traceability and archive prior meanings.

Version changes shall not silently alter the meaning of existing records. Where a semantic change affects Registry status, Marketplace listings, Reports, Studio workflows, Grid inputs, TRL notes, National Portfolio objects, Nexus Universe outputs, or handoff packages, correction propagation shall be considered.

### 7.4.5 Deprecation.

Deprecation shall mark a term, category, schema element, relationship, mapping, or ontology object as no longer preferred for active use while preserving historical meaning. Deprecation records shall identify the reason, successor term or object where applicable, effective date, affected objects, migration guidance, and archive status.

Deprecated terms shall not be silently reused for new meanings. Use of deprecated terms in active outputs shall require review or correction unless retained for historical reference.

### 7.4.6 Mapping.

Mapping shall define relationships between terms, taxonomies, schemas, categories, standards, frameworks, jurisdictions, languages, datasets, models, or object classes. Mapping may include exact match, close match, broad match, narrow match, related match, partial match, no match, conflict, or context-dependent relationship. Mapping shall include source, scope, confidence, limitations, version, steward, and correction pathway.

Mapping shall not create equivalence by default. Crosswalks to external taxonomies, standards, legal categories, credential systems, labor-market classifications, public authority classifications, or technical standards shall remain bounded and shall not imply adoption, compliance, certification, or authority.

### 7.4.7 Localization.

Localization shall adapt ontology, schema, vocabulary, taxonomy, and graph objects to national, regional, sectoral, legal, linguistic, cultural, public authority, community, Indigenous protocol-sensitive where applicable, and operational contexts while preserving semantic traceability. Localization shall include local terminology, legal context notes, public authority boundary notes, data sovereignty notes, public-safe notes, safeguard notes, and mapping to global Nexus terms.

Localization shall not create national authority, public authority adoption, country ranking, legal equivalence, regulatory status, or local consent by implication. Localized terms shall remain tied to records and correction pathways.

### 7.4.8 Translation.

Translation shall render terms, definitions, schemas, taxonomies, labels, public-safe summaries, notices, and ontology objects into another language while preserving scope, limitations, boundary language, and correctionability. Translation shall distinguish literal equivalence from functional equivalence and shall identify untranslatable, culturally sensitive, legally sensitive, or context-dependent terms.

Translation shall not constitute substantive approval, legal equivalence, public authority adoption, or new license. Where translated terminology could create overclaim, the translation shall include notes, restrictions, or review requirements.

### 7.4.9 Conflict resolution.

Semantic conflicts may arise from overlapping terms, competing definitions, jurisdictional differences, translation ambiguity, standards mismatch, public authority terminology, community meaning, protected knowledge, Indigenous protocol-sensitive meaning where applicable, financial or insurance terminology, or technical domain differences. Conflict resolution shall identify the conflict, affected objects, sources, stakes, interim use rule, reviewers, decision record, correction pathway, and archive treatment.

Where conflict cannot be resolved safely, DDPGF shall prefer bounded parallel terms, scope notes, restricted use, public-safe summaries, or non-continuation rather than forcing false equivalence.

### 7.4.10 Correction and archive.

Semantic correction shall address incorrect definitions, misleading labels, broken mappings, obsolete categories, harmful terms, inaccurate translations, schema errors, public authority overclaims, finance or insurance overclaims, procurement overclaims, safeguard failures, protected knowledge exposure, or knowledge graph errors. Correction actions may include erratum, addendum, revision, deprecation, supersession, withdrawal, mapping repair, translation repair, public-safe notice, Registry update, Marketplace update, Reports correction, Studio update, Grid update, TRL update, handoff recall, or archive.

Archive shall preserve prior semantic states for institutional memory while marking them as historical and non-current where appropriate.

## 7.5 Knowledge Graph Governance

### 7.5.1 Entity records.

Entity Records shall define the nodes represented in a Knowledge Graph Object, including digital objects, institutions, roles, systems, datasets, models, software, APIs, reports, workflows, indicators, risks, hazards, technologies, places, National Portfolio objects, Nexus Universe outputs, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, Proof Receipts, and handoff dependencies. Entity Records shall include identity, type, source, steward, access class, sensitivity class, public-safe status, version, lifecycle state, and correction pathway where applicable.

Entity Records shall not create legal identity, official status, endorsement, certification, public authority status, procurement qualification, financeability, insurability, consent, or execution authority by implication.

### 7.5.2 Relationship records.

Relationship Records shall define the links among entities, including dependency, derivation, evidence source, citation, ownership where recorded, stewardship, contribution, review, support, version, mapping, localization, translation, handoff relevance, correction relationship, archive relationship, and successor relationship. Relationship Records shall include relationship type, source, confidence, sensitivity, directionality, temporal status, limitations, and correction pathway.

A graph relationship shall not create agency, endorsement, liability, legal dependency, procurement relationship, financial relationship, insurance relationship, partnership, consent, public authority approval, or execution authority unless separately and lawfully recorded outside the graph.

### 7.5.3 Provenance records.

Provenance Records shall document where graph entities and relationships come from, including source documents, datasets, repositories, Reports, Registry records, Marketplace records, Studio workflows, DRI indicators, Observatory signals, GRIx mappings, human review, AI-assisted extraction, public authority learning records, National Portfolio records, Nexus Universe records, or handoff packages. Provenance shall include date, source class, method, reviewer, AI-use status, confidence, limitations, and correction pathway.

Provenance shall support trust, auditability, and correction. It shall not make the source official, complete, current, public, unrestricted, legally authoritative, or deployable.

### 7.5.4 Confidence labels.

Confidence Labels shall express the degree of confidence in an entity, relationship, mapping, inference, classification, or graph-derived view. Confidence may be based on source quality, review status, recency, consistency, evidence sufficiency, method quality, and uncertainty. Confidence Labels shall be documented and shall distinguish between evidence-backed records, inferred relationships, machine-assisted extraction, unreviewed drafts, controlled internal records, and public-safe outputs.

Confidence Labels shall not be ratings, rankings, investment signals, insurance signals, procurement scores, public authority determinations, or certification levels.

### 7.5.5 Sensitivity labels.

Sensitivity Labels shall identify whether graph entities, relationships, or views involve personal data, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, finance-sensitive data, procurement-sensitive data, confidential data, or handoff-recipient-only data. Sensitivity Labels shall drive access control, public-safe views, masking, aggregation, delay, restriction, or exclusion.

Sensitivity labeling shall not itself authorize access, publication, reuse, AI training, handoff, or disclosure. It shall signal controls and review needs.

### 7.5.6 Public-safe graph views.

Public-Safe Graph Views shall be graph-derived views that have been reviewed, redacted, aggregated, generalized, masked, contextualized, and approved for public-safe or controlled-public use. Public-safe views may support Reports, Marketplace discovery, Registry summaries, Academy learning, Campaign communication, Nexus Universe displays, National Portfolio summaries, or public-good dashboards.

Public-safe graph views shall avoid exposing sensitive relationships, protected knowledge, personal data, security-sensitive dependencies, infrastructure vulnerabilities, sensitive locations, community-sensitive details, Indigenous protocol-sensitive information where applicable, or public authority-sensitive details. They shall not function as rankings, ratings, warnings, official maps, public authority decisions, procurement signals, or finance signals.

### 7.5.7 Controlled graph views.

Controlled Graph Views shall be restricted views used for internal review, secure rooms, data rooms, clean rooms, protected knowledge rooms, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, Studio workflows, Grid review, TRL evidence review, or lawful handoff preparation. Controlled views shall apply access controls, logging, no-download controls where applicable, output review, sensitivity labels, and boundary notices.

Controlled access shall not create data rights, reuse rights, public authority approval, finance approval, insurance approval, procurement readiness, consent, deployment authorization, or execution authority.

### 7.5.8 Graph correction.

Graph correction shall address incorrect entities, incorrect relationships, outdated records, missing provenance, wrong confidence labels, wrong sensitivity labels, harmful inferences, privacy risks, protected knowledge exposure, public authority overclaim, finance or insurance overclaim, procurement overclaim, consent overclaim, or graph-derived misinformation. Correction may require entity update, relationship update, label update, view withdrawal, public-safe correction, Registry update, Marketplace update, Report correction, Studio update, Grid update, TRL update, handoff recall, and archive.

Graph correction shall propagate to downstream objects where a graph error has influenced discovery, reporting, review, readiness, learning, public-safe communication, or handoff.

### 7.5.9 Graph archive.

Graph archive shall preserve historical graph states, prior versions, deprecated relationships, withdrawn entities, archived views, correction history, provenance history, and successor links. Archived graph objects shall be marked as historical, non-current, restricted, or controlled where appropriate.

Archived graph material shall not be used as current evidence, current status truth, public-safe output, operational input, handoff context, or decision support unless separately reviewed and reactivated.

### 7.5.10 No-surveillance boundary.

Knowledge Graph Objects shall not be used to create unauthorized surveillance systems, social scoring systems, hidden profiling systems, worker ranking systems, community monitoring systems, public authority watchlists, financial scoring systems, insurance scoring systems, procurement blacklists, political profiling, protected knowledge extraction, or automated enforcement systems. Graph design shall minimize unnecessary personal data, restrict sensitive relationships, prevent inference harm, and avoid converting public-good interoperability into surveillance capability.

Any graph use involving people, communities, public authorities, sensitive locations, protected knowledge, youth, health, employment, finance, insurance, procurement, security, or infrastructure shall require heightened review, access controls, public-safe limits, and correction channels.

## 7.6 Ontology Boundary Rules

### 7.6.1 Category is not legal determination.

A category, label, taxonomy entry, ontology class, GRIx term, DRI term, Registry field, Marketplace label, Studio tag, Grid field, TRL field, Report category, National Portfolio category, Nexus Universe label, or handoff dependency category shall not constitute a legal determination by default. Legal status shall require separate competent authority, legal review, and recorded lawful basis outside semantic classification.

### 7.6.2 Risk label is not rating.

A risk label shall support meaning, routing, review, learning, public-safe reporting, and correction. It shall not constitute a risk rating, credit rating, insurance score, investment signal, public warning, country ranking, provider ranking, procurement score, safety certification, or official hazard determination by implication.

### 7.6.3 Semantic mapping is not equivalence by default.

A semantic mapping between terms, standards, taxonomies, schemas, jurisdictions, languages, credentials, data fields, model fields, reports, or categories shall not create equivalence by default. Mapping shall describe relationship within scope and may be exact, close, broad, narrow, partial, related, conflicting, or uncertain. Any claim of equivalence shall require explicit review and recorded basis.

### 7.6.4 Knowledge graph is not public authority record.

A Knowledge Graph Object shall not become a public authority record, public warning, official map, regulatory record, permit record, license record, inspection record, emergency command record, public finance record, or governmental decision record by default. Public authority records may be referenced where lawfully available and permitted, but graph inclusion shall not transform Nexus graph infrastructure into official authority.

### 7.6.5 Schema conformance is not certification.

Schema conformance means that an object follows a recorded structure. It shall not certify substantive quality, safety, legality, rights compliance, privacy compliance, cybersecurity, fairness, reliability, public-safe status, financeability, insurability, procurement readiness, deployment readiness, public authority approval, or execution authority. Substantive review, assurance, and lawful approval remain separate.

### 7.6.6 GRIx mapping is not standards authority.

GRIx mapping may connect Nexus risk language to standards, frameworks, taxonomies, protocols, public-safe reporting structures, disaster-risk language, climate and weather language, digital-public-good language, AI governance language, data governance language, cyber language, finance-readiness language, or handoff dependency language. Such mapping shall not make GRIx a standards authority, certification body, regulator, public authority, procurement body, finance body, insurance body, or legal equivalence authority. GRIx structures meaning for Nexus; it does not create external authority by implication.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/vii.-ontologies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.