# I. FOUNDATIONS

## 1.1 DDPGF Defined

### 1.1.1 Distributed Digital Public Goods Framework as the Nexus digital-public-goods architecture.

The **Distributed Digital Public Goods Framework (DDPGF)** shall constitute the Nexus architecture for the creation, governance, stewardship, review, publication, discovery, reuse, correction, localization, support, and lawful handoff of digital public-good objects. DDPGF shall operate as the digital-public-goods layer through which Nexus converts public-good needs, risk signals, research outputs, data assets, software artefacts, model artefacts, learning materials, dashboards, reports, ontologies, schemas, credentials, workflows, simulations, proof receipts, Registry records, Marketplace listings, Studio objects, Grid inputs, TRL notes, National Portfolio outputs, Nexus Universe outputs, Observatory signals, DRI indicators, GRIx categories, DICE objects, and handoff packages into governed digital objects capable of being reused without collapsing public-good activity into certification, procurement, finance, public authority action, consent, deployment, command, or execution.

DDPGF shall be read as a public-good digital infrastructure framework, not merely as an open-source policy, publication policy, data policy, software policy, repository policy, AI policy, platform policy, or knowledge-management policy. It shall provide the operating constitution for digital objects that must be open where safe, controlled where necessary, interoperable where useful, nationally localizable where required, evidence-bearing where relied upon, correctionable where wrong, archived where no longer current, and bounded against overclaim at every lifecycle stage.

### 1.1.2 DDPGF as the operating framework for reusable digital public-good objects.

DDPGF shall govern reusable digital public-good objects as structured, identifiable, versioned, metadata-bearing, stewarded, reviewable, support-classified, sensitivity-classified, license-aware, access-controlled, provenance-linked, correctionable, and archivable artefacts. A digital public-good object under DDPGF may be open, controlled, restricted, secure-room-only, data-room-only, national-repository-only, handoff-recipient-only, public-safe, internal, experimental, unsupported, supported, deprecated, withdrawn, recalled, archived, or non-continuing according to its recorded class and lifecycle state.

DDPGF shall ensure that reusable digital objects are not treated as informal files, ad hoc uploads, ungoverned tools, uncontrolled demonstrations, undocumented models, orphaned repositories, stale dashboards, unreviewed datasets, unsupported software, ambiguous templates, unbounded credentials, or public-facing claims without records. Reuse shall require object identity, scope, metadata, version, steward, license or use condition, access class, support class, review status, public-safe status, sensitivity class, correction pathway, and archive rule.

### 1.1.3 DDPGF as the software, data, model, knowledge, infrastructure, and commons framework of Nexus.

DDPGF shall provide the common Nexus framework for software commons, data commons, model commons, knowledge commons, ontology commons, learning commons, publication commons, repository commons, API and protocol commons, dashboard and visual commons, Studio workflow commons, Registry and Marketplace object governance, distributed infrastructure records, secure-room workflows, compute-to-data workflows, and national digital-public-good localization.

The framework shall apply across the full Nexus digital object universe, including without limitation: repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, adapters, command-line tools, notebooks, infrastructure-as-code templates, test suites, reference implementations, datasets, metadata records, schemas, data dictionaries, codebooks, pipelines, models, AI systems, agent workflows, model cards, system cards, benchmark cards, ontologies, taxonomies, GRIx categories, DRI indicators, Observatory objects, digital twins, simulations, reports, learning objects, micro-credentials, campaign objects, proof receipts, support ledgers, Registry records, Marketplace listings, Grid records, TRL evidence notes, National Portfolio objects, Nexus Universe outputs, and lawful handoff dependency packages.

### 1.1.4 DDPGF as a public-good alternative to proprietary platform capture.

DDPGF shall preserve Nexus digital-public-good activity against proprietary platform capture, sponsor capture, provider capture, data extraction, repository enclosure, hidden exclusivity, pay-to-prioritize, pay-to-validate, forced lock-in, unreviewed dependency capture, opaque model capture, closed data capture, credential capture, public authority overclaim, and downstream conversion of public-good outputs into private control without proper record, authority, and boundary discipline.

This section shall not prohibit lawful enterprise use, commercial support, hosted services, provider participation, sponsor support, national enterprise handoff, or Project SPV implementation where separately authorized and properly recorded. It shall require that such activity remain role-separated from the public-good stack, that public-good assets remain governed according to their license and use conditions, that provider or sponsor contribution does not create validation, and that enterprise use does not retroactively convert DDPGF objects into proprietary claims, procurement preference, certification status, public authority approval, investment status, insurance approval, or execution authority.

### 1.1.5 DDPGF as a distributed, federated, nationally grounded, globally interoperable architecture.

DDPGF shall be distributed by technical design, federated by governance, nationally grounded by localization discipline, and globally interoperable by common object identity, metadata, schema, lifecycle, licensing, access, review, Registry, Marketplace, correction, and archive rules. It shall support global coherence without global supremacy, regional coordination without regional override, national localization without semantic drift, and local reuse without bypassing national ownership, public authority boundaries, data sovereignty, community safeguards, Indigenous protocols where applicable, protected knowledge controls, and lawful handoff pathways.

DDPGF shall support national repositories, regional mirrors, global discovery layers, controlled repositories, secure repositories, public repositories, metadata-only records, offline packages, low-bandwidth access, sovereign hosting contexts, compute-to-data environments, and cross-border data-transfer controls. Interoperability shall not require uniformity, and localization shall not permit uncontrolled fragmentation. The framework shall preserve a common digital-public-good rail while allowing lawful national adaptation, translation, restricted access, sovereign-sensitive workflows, and public-safe publication.

### 1.1.6 DDPGF as a framework for resilience, all-hazards risk reduction, WFEH-B systems, and exponential-technology governance.

DDPGF shall support digital-public-good objects required for resilience, disaster risk reduction, disaster risk finance literacy, disaster risk intelligence, WFEH-B systems, climate adaptation, nature and biodiversity systems, infrastructure resilience, public health resilience, food systems, water systems, energy systems, cyber-physical resilience, supply-chain resilience, public authority learning, national capability formation, and exponential-technology governance.

DDPGF shall apply to digital objects involving AI, agentic systems, AI-RAN, O-RAN, telecom, private wireless, edge computing, high-performance computing, sovereign compute, cloud infrastructure, cybersecurity, geospatial systems, Earth observation, digital twins, drones, robotics, sensors, IoT, OT, IIoT, distributed ledgers, DePIN, Web3, digital identity, verification infrastructure, quantum-relevant security, semiconductors, advanced manufacturing, biosecurity-sensitive systems, frontier science infrastructure, and other emerging technologies. Its purpose is to make such objects usable, reviewable, interoperable, public-safe, correctionable, and handoff-ready without treating digital availability as authorization to deploy.

### 1.1.7 DDPGF as a framework for public-good digital assets without procurement, certification, finance, or execution by implication.

DDPGF shall govern digital public-good assets in a manner that preserves strict no-conversion discipline. No digital public-good object, open-source repository, dataset, model, dashboard, Studio workflow, Registry record, Marketplace listing, Grid input, TRL evidence note, report, credential object, proof receipt, National Portfolio object, Nexus Universe output, Observatory signal, DRI indicator, or handoff package shall, merely by being created, reviewed, listed, published, downloaded, cited, displayed, demonstrated, forked, reused, localized, or routed, create certification, standards conformance, procurement approval, supplier approval, vendor validation, investment readiness, financeability, insurability, underwriting approval, public authority approval, community consent, Indigenous consent, deployment authorization, operational command, public warning, emergency instruction, legal compliance determination, professional license, warranty, service-level commitment, or execution authority.

This rule shall apply across all DDPGF objects unless a separate competent authority, lawful recipient, contractual instrument, regulatory process, procurement process, public authority act, community consent process, Indigenous protocol process, enterprise handoff instrument, insurance process, finance process, or other lawful mechanism expressly creates such status outside the default operation of DDPGF.

### 1.1.8 DDPGF as the digital object governance layer for the Nexus Ecosystem.

DDPGF shall serve as the digital object governance layer for the Nexus Ecosystem by defining how digital objects enter the ecosystem, how they are classified, how they are stewarded, how they are reviewed, how they become public-safe or controlled, how they are published or restricted, how they become discoverable through Nexus Marketplace, how they become status-true through Nexus Registry, how they are routed through Nexus Rails, how they are used in Nexus Studio, how they are evaluated through Nexus Grid and TRL 1–10 evidence notes, how they support Nexus Academy and Risk Academy, how they are built through Nexus Foundry, how they inform Nexus Reports, how they support Nexus Campaigns, how they feed Nexus Observatory, DRI, GRIx, and DICE, how they appear in Nexus Universe, how they localize through National Nodes and National Portfolios, and how they may be packaged for lawful handoff.

DDPGF shall not replace the mandates of Nexus Foundry, DICE, GRIx, DRI, Nexus Observatory, Nexus Studio, Nexus Grid, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Academy, Risk Academy, Nexus Campaigns, Nexus Universe, Nexus Rails, Nexus Network, National Nexus Consortiums, National Working Groups, Competence Cells, National Consortium Companies, Project SPVs, public authorities, providers, operators, funders, insurers, communities, or lawful implementation actors. It shall provide the object-governance discipline through which those mechanisms can interact safely, coherently, and correctionably.

## 1.2 Foundational Thesis

### 1.2.1 From isolated digital projects to governed digital public-good ecosystems.

DDPGF shall shift Nexus digital activity from isolated digital projects toward governed digital public-good ecosystems. A digital project may produce a file, tool, dataset, dashboard, repository, model, report, or platform feature; DDPGF requires that the resulting artefact become a governed object with identity, metadata, provenance, steward, access class, lifecycle state, review status, support status, public-safe status, sensitivity class, correction pathway, and archive rule.

The purpose of this shift is to prevent fragmentation, duplication, abandoned assets, unsupported releases, ambiguous ownership, hidden dependencies, unclear rights, uncontrolled reuse, security drift, stale public-facing claims, inaccessible materials, and untraceable handoff. Digital-public-good ecosystems require continuity, memory, interoperability, stewardship, discoverability, accountability, localization, and correction.

### 1.2.2 From static files to lifecycle-governed digital objects.

DDPGF shall treat digital artefacts not as static files but as lifecycle-governed objects. A static file may be uploaded, shared, forgotten, misused, misquoted, or detached from its source. A lifecycle-governed digital object shall be created, classified, versioned, reviewed, supported, corrected, deprecated, withdrawn, recalled, archived, or marked non-continuing according to recorded rules.

This lifecycle discipline shall apply whether the object is a code repository, dataset, dashboard, model card, system card, benchmark card, report, public-safe summary, schema, API, credential object, ontology, proof receipt, Studio workflow, digital twin, simulation, DRI indicator, GRIx category, Registry record, Marketplace listing, or handoff package. DDPGF shall therefore make digital-public-good governance continuous rather than episodic.

### 1.2.3 From open-source alone to full-stack digital public goods.

DDPGF shall recognize open-source software as important but insufficient to define the full digital public-good stack. Full-stack digital public goods include software, data, metadata, models, AI systems, agent workflows, APIs, schemas, ontologies, dashboards, digital twins, simulations, notebooks, evidence packs, learning objects, credentials, reports, protocols, repositories, runtime workflows, secure-room processes, access controls, support records, correction records, localization records, and lawful handoff packages.

DDPGF shall therefore govern both openness and control. Some objects may be fully open; some may be public-safe summaries of controlled sources; some may be accessible only within secure rooms; some may be metadata-only; some may be available only to approved national actors; some may be handoff-recipient-only; some may be archived but not current; some may be withdrawn or recalled. The framework shall reject the false choice between unrestricted openness and closed proprietary control by establishing a disciplined public-good middle architecture.

### 1.2.4 From central platforms to federated commons.

DDPGF shall shift Nexus digital infrastructure from central-platform dependency toward federated commons. A central platform may concentrate access, control, data, identity, workflow, discovery, and dependency in a single technical or institutional surface. Federated commons shall distribute stewardship across global, regional, national, institutional, community, repository, secure-room, and handoff contexts while preserving common object governance.

Federated commons shall require shared rules for object identity, metadata, versioning, licensing, access classes, review gates, public-safe status, Registry status, Marketplace listing, correction, archive, localization, and no-conversion notices. Federation shall not mean disorder; it shall mean coherent plurality governed by common public-good object discipline.

### 1.2.5 From extractive data systems to governed data commons.

DDPGF shall shift Nexus data activity from extractive data systems toward governed data commons. Extractive systems collect, centralize, monetize, overexpose, infer, or repurpose data without adequate public-good discipline, data rights, consent, access control, sovereign sensitivity, community safeguard, Indigenous protocol sensitivity, protected knowledge treatment, purpose limitation, or correction. Governed data commons shall preserve data as an evidence-bearing and public-good object subject to classification, rights review, lineage, metadata, access controls, public-safe transformation, retention, deletion, sealing, localization, incident response, and archive.

DDPGF shall require that data availability never be confused with unrestricted data rights. Metadata may be public even where source data is controlled. Public-safe data may differ from raw data. Data-room access shall not create handoff permission. Compute-to-data may be required where data export would be unsafe, unlawful, extractive, sovereignty-sensitive, community-sensitive, cyber-sensitive, health-sensitive, infrastructure-sensitive, or protected-knowledge-sensitive.

### 1.2.6 From AI demos to verified, bounded, reviewable model and agent objects.

DDPGF shall shift AI activity from demonstrations, prototypes, and informal model use toward verified, bounded, reviewable model and agent objects. AI models, foundation-model interfaces, fine-tuned models, retrieval-augmented systems, classifiers, forecasting models, optimization models, simulation models, digital twin models, decision-support models, evaluation harnesses, and agentic workflows shall be governed as objects with intended use, prohibited use, data provenance, training or configuration constraints, evaluation records, bias and harm review, human review, tool permissions, prompt-injection controls, logging, incident response, withdrawal rules, and archive rules.

AI demonstrations shall not create authority. Model cards shall not constitute safety certification. Benchmark results shall not constitute general validation. Agent outputs shall not constitute determinations. AI workflows shall not create public authority decisions, procurement readiness, financeability, insurability, professional advice, legal compliance determinations, operational commands, or deployment authorization by implication.

### 1.2.7 From deployment-first technology to evidence-first, public-safe, correctionable digital goods.

DDPGF shall reverse deployment-first assumptions by requiring digital-public-good objects to move through evidence, review, public-safe transformation, support classification, Registry status, Marketplace listing, release classification, correction pathways, and archive rules before being relied upon or routed for handoff. Digital availability shall not be treated as readiness; demonstration shall not be treated as deployment; review shall not be treated as certification; publication shall not be treated as approval; and reuse shall not be treated as warranty.

Evidence-first digital goods shall include records of purpose, scope, sources, methods, dependencies, limitations, assumptions, access classes, license conditions, support status, public-safe controls, sensitivity labels, review status, and correction pathways. Public-safe digital goods shall be structured so that they can be shared without creating unsafe claims, exposing protected knowledge, revealing sensitive locations, implying public authority approval, creating finance or procurement signals, or enabling harmful operational misuse. Correctionable digital goods shall remain amendable, suspendable, withdrawable, recallable, supersedable, and archivable.

### 1.2.8 From digital access to digital sovereignty, interoperability, and lawful handoff.

DDPGF shall move beyond digital access alone toward digital sovereignty, interoperability, and lawful handoff. Access is not enough where digital objects are not locally understandable, legally usable, technically interoperable, accessible to persons with disabilities, usable in low-bandwidth environments, available in relevant languages, aligned with national data sovereignty, or safe for public-good reuse.

DDPGF shall support national localization, national repositories, sovereign compute contexts, cross-border transfer controls, national metadata, public authority-sensitive workflows, community and Indigenous protocol safeguards, protected knowledge controls, accessibility requirements, low-bandwidth and offline access, open interfaces, common schemas, and handoff packages that transfer context and dependencies without transferring authority. Lawful handoff shall occur only where competent actors separately accept responsibility, conduct independent diligence, satisfy legal requirements, and assume execution obligations outside DDPGF default posture.

## 1.3 DDPGF Operating Formula

### 1.3.1 Needs become digital-public-good objects.

DDPGF shall convert public-good needs into digital-public-good object candidates. Such needs may arise from National Portfolios, Nexus Universe arenas, Nexus Foundry programs, DICE workflows, GRIx mapping, DRI indicators, Nexus Observatory signals, Nexus Studio workflows, Nexus Academy and Risk Academy learning pathways, Nexus Campaigns, Nexus Reports, Nexus Marketplace demand signals, Nexus Registry gaps, public authority learning questions, national capability gaps, community safeguard concerns, technology-readiness gaps, data gaps, software gaps, standards-interface gaps, and lawful handoff dependency gaps.

A need shall not become a digital-public-good object merely because a stakeholder requests it, funds it, builds it, demonstrates it, uploads it, or promotes it. It shall become a DDPGF object candidate only when its purpose, scope, proposed object class, source pathway, steward, access class, likely sensitivity, public-good rationale, review pathway, and boundary conditions are recorded.

### 1.3.2 Objects become records.

Each digital-public-good object shall become a record before it becomes a released, listed, published, routed, or handoff-relevant artefact. The record shall identify the object, its steward, version, source pathway, object family, object class, purpose, intended use, prohibited use where applicable, source materials, dependencies, license or use conditions, access class, sensitivity class, data-use label, AI-use label, review status, public-safe status, support class, correction pathway, archive rule, localization status, and no-conversion notices.

The record shall be sufficient to establish the object’s identity and lifecycle memory without implying certification, warranty, approval, procurement status, public authority status, financeability, insurability, consent, deployment authorization, or execution authority.

### 1.3.3 Records become reviewed artefacts.

Digital object records shall route the underlying artefact to review according to object class, sensitivity, intended use, public-facing risk, data status, AI status, cybersecurity status, privacy status, public authority relevance, finance or insurance relevance, procurement relevance, protected knowledge relevance, community relevance, Indigenous protocol relevance where applicable, geospatial sensitivity, infrastructure sensitivity, and handoff relevance.

Reviewed artefacts may be approved for continued development, restricted access, public-safe transformation, internal use, secure-room use, Studio-only use, data-room use, Registry recording, Marketplace listing, publication, national localization, handoff packaging, correction, suspension, withdrawal, archive, or non-continuation. Review shall remain bounded. Review does not create certification unless a separate competent certification process exists and is expressly recorded outside default DDPGF status.

### 1.3.4 Artefacts become reusable software, data, model, report, dashboard, learning, Studio, Registry, Marketplace, Grid, TRL, and handoff objects.

Reviewed artefacts may become reusable digital public-good objects within one or more Nexus pathways. A software artefact may become a repository, library, service, application, API, SDK, connector, adapter, dashboard, notebook, infrastructure-as-code template, or reference implementation. A data artefact may become a dataset, metadata record, schema, data dictionary, codebook, data pipeline, feature set, DRI dataset, Observatory dataset, or National Portfolio dataset. A model artefact may become a model card, system card, benchmark card, AI workflow object, agent workflow card, simulation model, digital twin model, or evaluation harness. A knowledge artefact may become a report, public-safe summary, learning object, credential object, campaign object, or handoff literacy object.

Each reusable object shall retain its lifecycle record and shall be routed according to its recorded class. Reuse shall be governed by license, access, support, sensitivity, review, and correction conditions.

### 1.3.5 Objects become discoverable through Marketplace and status-true through Registry.

DDPGF objects that are appropriate for discovery shall be listed or referenced through Nexus Marketplace according to listing governance, metadata quality, public-safe review, license review, support-class review, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, and correction readiness. Marketplace discovery shall enable awareness, reuse, learning, contribution, support, and handoff awareness without creating endorsement, procurement status, validation, approval, or finance signal.

DDPGF objects that require lifecycle memory shall be recorded through Nexus Registry according to status-truth rules. Registry status shall preserve object identity, version, review state, support state, correction state, archive state, withdrawal state, recall state, and boundary notices. Registry recordation shall create status truth for the Nexus ecosystem but shall not constitute universal validation, certification, approval, or legal authority.

### 1.3.6 Public-safe objects become publishable through Nexus Reports and repositories.

DDPGF objects that satisfy public-safe requirements may be published through Nexus Reports, public repositories, open repositories, data repositories, model repositories, learning repositories, national repositories, or comparable publication channels. Publication shall require appropriate metadata, license or use conditions, citation information, versioning, data availability statement, AI-use statement where applicable, support statement, public-safe abstract where applicable, correction pathway, archive rule, and no-conversion notice.

Public-safe publication shall not mean unrestricted use. Public-facing availability shall not remove license conditions, data-use limits, AI-use limits, attribution requirements, sensitivity constraints, community safeguards, Indigenous protocols where applicable, protected knowledge restrictions, cyber-sensitive controls, geospatial masking, or public authority boundary rules.

### 1.3.7 Controlled objects remain governed through DICE, Studio, secure rooms, data rooms, and national repositories.

Objects that are not suitable for open publication shall remain governed through DICE, Nexus Studio, secure rooms, data rooms, clean rooms, protected knowledge rooms, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, national repositories, sovereign repositories, controlled repositories, metadata-only records, or handoff-recipient-only packages. Controlled status shall not be treated as failure; it shall be treated as appropriate public-good governance where openness would be unsafe, unlawful, extractive, sovereignty-sensitive, rights-sensitive, cyber-sensitive, infrastructure-sensitive, community-sensitive, Indigenous-protocol-sensitive, protected-knowledge-sensitive, or misleading.

Controlled objects shall remain reviewable, traceable, support-classified, correctionable, and archivable. Access shall be governed by role, permission, purpose, jurisdiction, sensitivity, data rights, public-safe rules, and recorded use conditions.

### 1.3.8 Correction keeps all digital public goods trustworthy.

Correction shall be a core operating condition of DDPGF. Every digital public-good object shall have a correction pathway before release, listing, publication, controlled access, or handoff routing. Correction may include patch, erratum, addendum, revision, supersession, downgrade, suspension, withdrawal, retraction where necessary, recall, public repair, archive, non-continuation, or handoff recall.

Correction shall apply to software errors, data errors, model errors, metadata errors, license errors, public-safe errors, AI-use errors, security vulnerabilities, privacy incidents, protected knowledge incidents, public authority overclaims, finance overclaims, procurement overclaims, provider validation incidents, sponsor control incidents, consent overclaims, handoff overclaims, execution overclaims, outdated support status, inaccurate Registry status, misleading Marketplace listing, or unsafe publication. Trust shall arise not from the claim that digital objects are perfect, but from the fact that their errors can be found, recorded, corrected, propagated, and archived.

## 1.4 DDPGF Public-Good Principles

### 1.4.1 Public-good by design.

DDPGF objects shall be designed to serve public-good purposes, including resilience, risk reduction, learning, evidence, observability, interoperability, public-safe knowledge, national capability formation, public authority learning, digital commons, open technical baselines, secure controlled access, and lawful handoff context. Public-good design shall not require that every object be open to all users in all forms. It shall require that the object be governed for public-good use, bounded against capture, documented against misuse, and corrected when necessary.

### 1.4.2 Distributed by architecture.

DDPGF shall prefer distributed architecture where distribution increases resilience, accessibility, localization, continuity, sovereignty, interoperability, and ecosystem participation. Distribution may occur through repositories, mirrors, national nodes, regional clusters, edge environments, secure rooms, data rooms, sovereign compute environments, federated storage, offline packages, low-bandwidth formats, and local stewarding arrangements.

Distribution shall not mean uncontrolled replication. Distributed objects shall preserve identity, provenance, versioning, license conditions, access classes, sensitivity labels, support classes, correction pathways, archive rules, and no-conversion notices.

### 1.4.3 Federated by governance.

DDPGF shall be federated by governance, allowing multiple institutions, countries, nodes, repositories, rooms, programs, and stewards to participate in digital-public-good production and reuse under common rules. Federation shall preserve role separation among GCRI, The Global Risks Forum, The Global Risks Alliance, Nexus bodies, public authorities, national consortiums, providers, sponsors, communities, National Consortium Companies, Project SPVs, and lawful implementation actors.

Federated governance shall prevent both centralized capture and ungoverned fragmentation. It shall use common object metadata, Registry status, Marketplace listing rules, review gates, support classes, public-safe controls, licensing discipline, correction mechanisms, and archive rules to keep a distributed ecosystem coherent.

### 1.4.4 Open where safe.

DDPGF shall favor openness where openness advances public-good access, reuse, learning, transparency, reproducibility, interoperability, resilience, public-safe publication, and national capability formation without causing legal, ethical, safety, security, privacy, community, Indigenous protocol, protected knowledge, cyber, infrastructure, geospatial, health, youth, public authority, or handoff harm.

Open objects may include open-source repositories, open technical baselines, public-safe datasets, public reports, learning objects, schemas, APIs, documentation, notebooks, dashboards, summaries, metadata, model cards, system cards, benchmark cards, and other artefacts suitable for public release. Openness shall be accompanied by license terms, attribution, support status, limitations, no-warranty notices, no-certification notices, correction pathways, and archive rules.

### 1.4.5 Controlled where necessary.

DDPGF shall require controlled access where openness would be unsafe, unlawful, extractive, misleading, rights-invasive, sovereignty-sensitive, protected-knowledge-sensitive, cyber-sensitive, infrastructure-sensitive, health-sensitive, youth-sensitive, community-sensitive, Indigenous-protocol-sensitive, geospatially sensitive, dual-use sensitive, commercially confidential, public authority-sensitive, or handoff-sensitive.

Controlled access may include secure rooms, data rooms, clean rooms, compute-to-data, protected knowledge rooms, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, national repositories, sovereign repositories, metadata-only records, and handoff-recipient-only packages. Control shall be recorded, proportionate, reviewable, and correctionable.

### 1.4.6 Interoperable by default.

DDPGF shall promote interoperability by default through common object identity, metadata, schemas, APIs, protocols, controlled vocabularies, ontology mappings, data-use labels, AI-use labels, license classes, access classes, review statuses, support classes, correction statuses, Registry statuses, Marketplace listing metadata, public-safe notices, and handoff package structures.

Interoperability shall not create certification or standards authority by implication. A DDPGF object may be mapped to external standards, protocols, schemas, or reference practices without becoming certified, legally compliant, procurement-ready, finance-ready, or officially adopted. Conformance questions shall remain questions until separately decided by competent authority or authorized process.

### 1.4.7 Accessible and inclusive by design.

DDPGF objects shall be designed for accessibility, inclusion, linguistic diversity, disability inclusion, low-bandwidth use, offline use where appropriate, mobile access where appropriate, plain-language access where appropriate, and national localization. Digital public goods that cannot be found, understood, used, corrected, or safely localized by intended users shall not satisfy DDPGF public-good expectations.

Accessibility shall include, where applicable, screen-reader compatibility, alt text, captions, transcripts, plain-language summaries, multilingual metadata, accessible file formats, low-bandwidth alternatives, offline packages, assistive-technology compatibility, and correction channels for accessibility defects.

### 1.4.8 Secure and privacy-preserving by design.

DDPGF objects shall be secure and privacy-preserving by design. Security and privacy controls shall include, as applicable, least privilege, access control, identity controls, encryption where appropriate, secure repositories, secret scanning, dependency scanning, SBOM records, vulnerability disclosure, threat modeling, data minimization, purpose limitation, consent and permission records, cross-border controls, data sovereignty, retention limits, deletion, sealing, incident response, and archive controls.

Security review shall not constitute security certification by default. Privacy labeling shall not constitute legal compliance determination by default. Secure-room access shall not constitute safety approval. Vulnerability disclosure shall not constitute public warning. Digital resilience features shall not constitute service guarantee.

### 1.4.9 Evidence-bearing by record.

DDPGF objects shall be evidence-bearing by record. Each object shall be accompanied by sufficient evidence to understand its source, purpose, scope, method, assumptions, limitations, dependencies, review status, support status, access class, sensitivity class, public-safe status, license status, and correction pathway. Evidence-bearing status shall not mean that the object is complete, certified, approved, validated for all uses, or safe for deployment.

The purpose of evidence-bearing records is to make digital objects inspectable, reusable, correctable, and responsibly handoff-relevant within their recorded scope. Evidence shall be bounded by its source, method, review level, context, confidence, uncertainty, and limitations.

### 1.4.10 Correctable by lifecycle.

DDPGF objects shall be correctable by lifecycle. No object shall be treated as permanently valid merely because it was released, listed, published, downloaded, cited, demonstrated, or used in a Nexus context. Every object shall remain subject to correction, addendum, revision, patch, downgrade, suspension, withdrawal, recall, supersession, archive, or non-continuation.

Correctionability shall apply to technical errors, factual errors, data errors, model errors, security issues, privacy issues, license errors, misleading claims, overclaims, outdated records, broken dependencies, changed legal contexts, changed public-safe status, changed support status, and changed handoff relevance.

### 1.4.11 Nationally localizable.

DDPGF objects shall be nationally localizable where national context matters. Localization may include translation, legal-context adjustment, public authority terminology, national data sovereignty, national repository routing, local infrastructure adaptation, accessibility adaptation, cultural adaptation, community safeguard alignment, Indigenous protocol alignment where applicable, national public-safe review, and national handoff conditions.

Localization shall not create public authority adoption, legal equivalence, standards adoption, community consent, Indigenous consent, procurement status, finance status, or deployment authorization by implication. Localization shall preserve object identity, version relationship, source provenance, license conditions, correction pathway, and semantic coherence.

### 1.4.12 Non-executing by default.

DDPGF shall be non-executing by default. The creation, review, publication, listing, Registry recordation, demonstration, reuse, localization, or handoff packaging of a digital object shall not cause Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, a Nexus body, a National Nexus Consortium, a National Working Group, a Competence Cell, a provider, a sponsor, a public authority participant, a capital reader, an insurer, a community participant, or a contributor to execute a project, operate infrastructure, make a public authority decision, issue a public warning, approve procurement, provide finance, underwrite risk, certify conformance, grant consent, deploy technology, or assume implementation responsibility by implication.

Execution may occur only through separate competent lawful actors, instruments, approvals, contracts, mandates, procurement processes, public authority actions, consent processes, finance processes, insurance processes, National Consortium Companies, Project SPVs, operators, providers, contractors, or other lawful pathways outside DDPGF default status.

## 1.5 DDPGF Boundary Rules

### 1.5.1 Digital public good is not certification.

A DDPGF digital public-good object shall not constitute certification, conformity assessment, compliance determination, standards conformance, professional qualification, maturity certification, product approval, model safety approval, cybersecurity certification, sustainability certification, green claim validation, procurement eligibility, or deployment authorization merely because it is governed, reviewed, listed, published, cited, downloaded, reused, localized, or recorded. Certification may exist only where a separate competent certification process is expressly authorized and recorded outside the default DDPGF object status.

### 1.5.2 Open-source release is not warranty.

An open-source release, public-good software release, reference implementation, API, SDK, connector, adapter, dashboard, notebook, infrastructure-as-code template, or repository made available under DDPGF shall not create warranty, service-level commitment, fitness-for-purpose representation, production approval, security certification, provider validation, procurement recommendation, or deployment authorization by implication. Support status shall be separately recorded, and unsupported, community-supported, maintainer-supported, time-limited, handoff-recipient-supported, or archived status shall be clearly distinguishable.

### 1.5.3 Dataset publication is not unrestricted data right.

Publication, listing, sharing, citation, download, access, metadata display, repository deposit, or public-safe transformation of a dataset shall not create unrestricted data rights, permission to reuse beyond license or use conditions, permission to re-identify, permission to combine, permission to train AI systems, permission to export across borders, permission to publish raw data, permission to use protected knowledge, permission to access controlled sources, or permission to rely on the dataset for public authority, finance, insurance, procurement, operational, or deployment decisions. Data rights, data-use labels, AI-use labels, access classes, sensitivity classes, and license conditions shall govern.

### 1.5.4 Model release is not AI safety approval.

Release, publication, listing, demonstration, benchmarking, carding, evaluation, or Registry recordation of a model, AI system, foundation-model interface, fine-tuned model, retrieval-augmented system, classifier, forecasting model, risk model, optimization model, simulation model, digital twin model, decision-support model, evaluation harness, or agentic workflow shall not create AI safety approval, public authority approval, deployment authorization, professional advice, legal compliance determination, procurement readiness, financeability, insurability, or permission for automated high-stakes decision-making. Human review, AI-use labels, model cards, system cards, benchmark cards, and agent workflow controls shall remain bounded controls, not universal validation.

### 1.5.5 Dashboard is not public authority decision.

A dashboard, visualization, map, atlas, DRI interface, Observatory output, Studio display, digital twin view, simulation output, scenario result, indicator panel, metric display, or operating-intelligence view shall not constitute a public authority decision, public warning, official map, emergency command, legal classification, country ranking, provider rating, investment signal, insurance score, procurement recommendation, or deployment instruction. Dashboard outputs shall be treated as public-safe, controlled, or internal interpretation objects according to their recorded status and limitations.

### 1.5.6 Marketplace listing is not procurement approval.

Listing, featuring, categorizing, describing, ranking by internal display logic, tagging, linking, or making discoverable any digital object through Nexus Marketplace shall not constitute procurement approval, supplier approval, vendor validation, endorsement, preferred-provider status, due diligence completion, tender support, public authority adoption, finance readiness, insurability, certification, or implementation authorization. Marketplace shall support discovery and reuse within recorded boundaries only.

### 1.5.7 Registry record is not universal validation.

Registry recordation shall preserve status truth, lifecycle memory, version history, review status, support status, correction status, access class, license class, and archive status. Registry recordation shall not constitute universal validation, certification, approval, compliance determination, legal equivalence, procurement readiness, financeability, insurability, public authority decision, community consent, deployment authorization, or current authority for archived, withdrawn, recalled, superseded, or non-continuing objects.

### 1.5.8 Studio workflow is not deployment authorization.

A Nexus Studio workflow, simulation, controlled runtime, public authority learning room, readiness room, secure-room workflow, data-room workflow, AI review workflow, capital-reader room, insurance-reader room, donor-reader room, digital twin workflow, dashboard workflow, or controlled demonstration shall not constitute deployment authorization, operational command, production approval, public authority decision, finance approval, underwriting decision, procurement approval, data access right, handoff permission, or consent. Studio outputs shall remain bounded learning, demonstration, review, and evidence objects unless separately converted through lawful channels outside DDPGF default status.

### 1.5.9 Grid or TRL record is not financeability.

A Nexus Grid input, Grid status, TRL 1–10 evidence note, readiness classification, quality review, support status, maturity input, or release gate record shall not create financeability, bankability, insurability, underwriting approval, public finance approval, donor commitment, procurement readiness, certification, public authority approval, implementation authorization, or deployment permission. Grid and TRL records shall classify bounded evidence and support readiness memory within scope only.

### 1.5.10 Handoff package is not execution authority.

A lawful handoff dependency package, handoff context note, evidence package, data context, method context, Studio context, Grid context, TRL context, public-safe status note, safeguard status note, public authority dependency note, finance or insurance question note, procurement boundary note, provider-neutrality note, sponsor-boundary note, recipient responsibility note, or correction and recall pathway shall transfer context and dependencies only. It shall not transfer authority, mandate, approval, consent, finance, insurance, procurement status, public authority decision, operational command, legal responsibility, implementation duty, or execution authority by implication. Execution shall remain the responsibility of competent lawful actors acting through separate lawful instruments and processes.


---

# 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/i.-foundations.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.