# III. INTERFACES ## 3.1 DDPGF Within Nexus ### 3.1.1 DDPGF as the digital commons layer of Nexus. DDPGF shall serve as the digital commons layer of Nexus by establishing the common public-good architecture through which reusable software, data, models, AI-agent workflows, ontologies, schemas, APIs, dashboards, digital twins, simulations, notebooks, reports, learning objects, credential objects, campaign objects, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL evidence notes, proof receipts, National Portfolio objects, Nexus Universe outputs, Observatory signals, DRI indicators, GRIx categories, and lawful handoff packages are created, classified, reviewed, versioned, licensed, listed, published, supported, corrected, withdrawn, recalled, archived, and made available for reuse within recorded boundaries. DDPGF shall not be treated as a general technology catalogue, an uncontrolled open-source repository, a data lake, a model-sharing site, an enterprise software marketplace, a procurement portal, a standards authority, or an execution platform. It shall operate as the record-bearing digital public-good layer of Nexus, designed to make digital objects findable, interoperable, reusable, public-safe, secure, privacy-preserving, nationally localizable, correctionable, and lawful-handoff-ready without converting digital availability into certification, approval, procurement, finance, public authority action, consent, deployment, command, or execution. ### 3.1.2 DDPGF as the object governance layer for Nexus Foundry. DDPGF shall govern the digital objects produced, assembled, adapted, reviewed, packaged, released, listed, or archived through Nexus Foundry. Foundry programs, tracks, quests, bounties, builds, micro-builds, maintainers, review gates, release classes, and correction loops shall use DDPGF to ensure that every software build, data build, model build, ontology build, dashboard build, Studio workflow build, Marketplace object build, Registry record build, Grid input build, TRL evidence build, National Portfolio build, Reports build, Campaign build, and handoff dependency build receives an object identity, steward, version, metadata record, evidence class, access class, support class, license class, public-safe status, correction pathway, and archive rule. DDPGF shall allow Foundry to produce at ecosystem scale without collapsing production into execution. A Foundry build governed under DDPGF may become a reusable digital public-good object, learning object, public-safe report, Registry record, Marketplace listing, Studio workflow, Grid input, TRL note, Nexus Universe output, National Portfolio object, or lawful handoff context, but it shall not by default become a certified product, approved vendor asset, public authority tool, financeable asset, insured asset, deployment authorization, operational command, or executed project. ### 3.1.3 DDPGF as the software and data backbone of Nexus Studio. DDPGF shall provide the governed software, data, model, API, dashboard, digital twin, simulation, notebook, secure-room, data-room, clean-room, compute-to-data, and controlled workflow object layer that enables Nexus Studio to operate as a controlled runtime, simulation, demonstration, public authority learning, readiness-room, capital-reader-room, insurance-reader-room, donor-reader-room, AI output review, secure data workflow, and Nexus Universe demonstration environment. Studio workflows shall draw from DDPGF objects only within recorded access, data-use, AI-use, sensitivity, public-safe, security, privacy, and safeguard limits. Studio use shall not change object status unless a Registry update, correction record, review record, or lifecycle event is separately recorded. DDPGF shall preserve the distinction between Studio demonstration and deployment, simulation and certification, dashboard viewing and decision, digital twin use and operational control, AI output and determination, readiness-room review and finance approval, and public authority learning and public authority action. ### 3.1.4 DDPGF as the object listing source for Nexus Marketplace. DDPGF shall supply the governed object base from which Nexus Marketplace listings are generated. Marketplace listings shall be derived from DDPGF object records and shall display only approved metadata, descriptions, access class, support class, license class, Registry status, review status, public-safe status, steward information, correction pathway, archive rule, and boundary notices. Marketplace listings shall support discovery, learning, reuse, contribution, support, translation, localization, accessibility, and handoff awareness, but shall not function as procurement approval, vendor endorsement, provider validation, product certification, finance signal, insurance approval, public authority recommendation, or implementation authorization. DDPGF shall require Marketplace listing governance for every listed object, including metadata review, license review, public-safe review, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, and correction/delisting procedures where applicable. Marketplace discovery shall remain subordinate to Registry status truth and DDPGF lifecycle controls. ### 3.1.5 DDPGF as the object status source for Nexus Registry. DDPGF shall define the object status structure that Nexus Registry records, displays, preserves, and corrects. Registry status shall reflect DDPGF lifecycle states, including concept, intake, classified, draft, in build, in review, public-safe transformed, Registry-recorded, Marketplace-listed, published, supported, unsupported, deprecated, suspended, corrected, superseded, withdrawn, recalled, archived, and non-continuing. Registry records shall preserve object identity, version, steward, review status, access class, data-use label, AI-use label, license class, support class, public-safe status, sensitivity class, correction history, archive state, and boundary notices. Registry status shall be status truth within Nexus, not universal validation. A Registry record shall not create certification, legal equivalence, public authority approval, procurement status, financeability, insurability, consent, deployment authorization, or execution authority. DDPGF shall require correction propagation from object records to Registry records whenever the object is corrected, downgraded, suspended, withdrawn, recalled, superseded, archived, or marked non-continuing. ### 3.1.6 DDPGF as the publication artefact source for Nexus Reports. DDPGF shall provide the publication artefact layer for Nexus Reports by governing the report objects, datasets, software packages, notebooks, model cards, system cards, benchmark cards, dashboard snapshots, public-safe summaries, technical notes, repository packages, metadata, license files, data availability statements, AI-use statements, support statements, correction pathways, archive records, and no-conversion notices that support public-safe knowledge distribution. A DDPGF-governed object may be routed to Nexus Reports only after appropriate classification, evidence review, public-safe review, sensitivity review, license review, and boundary review. Publication through Reports shall not convert a digital public-good object into approval, public warning, certification, financeability, procurement readiness, public authority decision, country ranking, deployment authorization, or execution authority. Reports shall preserve DOI discipline, repository discipline, FAIR-aligned metadata where appropriate, controlled knowledge exclusions, protected knowledge controls, and correction/withdrawal/archive pathways. ### 3.1.7 DDPGF as the reusable object layer for Nexus Academy and Risk Academy. DDPGF shall supply the reusable digital object layer through which Nexus Academy and Risk Academy access, produce, adapt, translate, localize, display, update, and archive learning objects, risk literacy materials, public-safe reporting exercises, Studio exercises, software notebooks, data literacy objects, AI-use training objects, cyber and privacy learning objects, DRI indicator learning objects, GRIx taxonomy learning objects, Observatory learning objects, Foundry contributor tasks, WILP artefacts, micro-credential evidence objects, and competency-linked resources. DDPGF shall ensure that learning reuse does not create credential overclaim, professional license status, employment status, procurement qualification, public authority competence, deployment authorization, or execution authority. Learning objects shall preserve source identity, version, review state, public-safe state, accessibility status, localization status, data-use labels, AI-use labels, correction pathway, and archive rule. Academy and Risk Academy pathways may teach use, contribution, interpretation, and public-safe communication of DDPGF objects, but shall not convert learning completion into approval of any object, system, provider, person, public authority action, or implementation pathway. ### 3.1.8 DDPGF as the digital backbone for Nexus Universe and National Portfolios. DDPGF shall serve as the digital backbone for Nexus Universe and National Portfolios by making national, regional, thematic, sectoral, WFEH-B, DRR, DRF, DRI, technology, public authority learning, Foundry, Campaign, Academy, Reports, Studio, Grid, Marketplace, Registry, Observatory, and handoff objects traceable, reusable, comparable within scope, public-safe, nationally localizable, and correctionable across annual cycles. National Portfolios shall use DDPGF to record national context objects, national systems-risk maps, national challenge briefs, evidence need records, Observatory need records, Core Build requests, safeguard records, public authority learning records, readiness question records, Competence Cell workplans, Universe arena routing records, national dashboard objects, national DRI objects, national software objects, national data objects, national Reports objects, national Studio objects, national Marketplace objects, and national handoff objects. Nexus Universe shall use DDPGF to preserve arena records, participation records, Core Build records, room records, public authority learning records, readiness question records, support records, Marketplace listings, Registry updates, Reports, Campaign updates, Foundry continuation records, National Portfolio updates, handoff dependency notes, correction records, and archive records. DDPGF shall ensure that national display, Universe visibility, public authority presence, sponsor presence, provider demonstration, capital-reader attendance, insurance-reader attendance, media attention, or Marketplace discovery does not create endorsement, public authority approval, financeability, insurability, procurement status, certification, consent, deployment authorization, or execution authority. ## 3.2 Institutional Triad Roles ### 3.2.1 The Global Centre for Risk and Innovation as public-good software, methods, ontology, observability, verifiable compute, and evidence steward. The Global Centre for Risk and Innovation shall function within DDPGF as the evidence, methods, ontology, observability, public-good R\&D, public-good software, open technical baseline, verifiable compute, and intelligence steward for DDPGF objects within its recorded role. Its DDPGF responsibilities may include development of methods, schemas, controlled vocabularies, GRIx structures, DRI logic, observability methods, public-good software, reference implementations, open technical baselines, model and system card methods, benchmark card methods, reproducibility packages, compute-to-data patterns, secure-room methods, data lineage practices, evidence pack practices, technical review practices, and verifiable compute or verifiable intelligence records. The Global Centre for Risk and Innovation shall not, by virtue of DDPGF stewardship, become a certifier, procurement authority, finance actor, insurer, public authority, standards authority, execution vehicle, project developer, operator, or guarantor of downstream implementation. Its role shall be to make digital public-good objects more evidence-bearing, methodologically coherent, technically reviewable, ontologically structured, observability-ready, reproducible where feasible, public-safe where publishable, and correctionable across lifecycle states. ### 3.2.2 The Global Risks Forum as public-good legitimacy, claims discipline, Registry, public-safe reporting, and correction steward. The Global Risks Forum shall function within DDPGF as the public-good legitimacy, claims discipline, Registry, recognition-interface, maturity-record, public-safe reporting, stakeholder formation, public narrative, public-facing knowledge, correction, and archive steward for DDPGF objects within its recorded role. Its responsibilities may include governance of public-safe claims, Registry status language, Marketplace listing language, report publication language, public-safe abstracts, correction notices, withdrawal notices, archive notices, maturity-input language, no-conversion notices, stakeholder-facing object summaries, participation records, and public-good legitimacy records. The Global Risks Forum shall not, by virtue of DDPGF stewardship, create certification, legal compliance, public authority approval, procurement status, financeability, insurability, community consent, Indigenous consent, deployment authorization, or execution authority. Its role shall be to prevent overclaim, preserve public-good meaning, ensure public-safe reporting, maintain status truth through Registry discipline, support correction and public repair, and make DDPGF outputs understandable without converting them into authority by implication. ### 3.2.3 The Global Risks Alliance as finance-readiness, capital-readability, insurance-readiness, DRF, no-reliance, and regulated-perimeter steward. The Global Risks Alliance shall function within DDPGF as the finance-readiness, capital-readability, insurance-readiness, disaster-risk-finance, diligence-gap, no-reliance, non-transactional, non-soliciting, regulated-perimeter, and capital-reader literacy steward for DDPGF objects within its recorded role. Its responsibilities may include defining finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, assumptions registers, dependency registers, diligence-gap registers, no-reliance statements, capital-reader room object controls, insurance-reader room object controls, donor-reader room object controls, finance-boundary notices, and handoff-context financial perimeter controls. The Global Risks Alliance shall not, by virtue of DDPGF stewardship, act as a broker, dealer, investment adviser, lender, underwriter, insurer, reinsurer, guarantor, rating agency, fund, transaction platform, securities platform, donor allocation body, public finance authority, procurement body, or execution vehicle by default. Its role shall be to make DDPGF objects more readable to lawful capital, insurance, donor, and public finance audiences without converting object records into investment advice, solicitation, financeability, bankability, insurability, underwriting, public finance allocation, or regulated financial activity. ### 3.2.4 Coordinated digital-public-good arc without merger. DDPGF shall recognize the institutional triad as a coordinated digital-public-good arc in which The Global Centre for Risk and Innovation strengthens evidence, methods, ontology, observability, public-good software, and verifiable compute; The Global Risks Forum strengthens legitimacy, claims discipline, Registry status truth, public-safe reporting, stakeholder formation, public narrative, and correction; and The Global Risks Alliance strengthens finance-readiness, capital-readability, insurance-readiness, disaster-risk-finance literacy, diligence-gap identification, and regulated-perimeter discipline. This coordinated arc shall not merge institutional identities, collapse legal separateness, create hidden agency, create shared liability, combine governance authority, or transfer authority from one institution to another. Each institution shall act only within its recorded role, legal capacity, governance instruments, approved policies, and boundary notices. Cross-institutional coordination shall be recorded where it affects DDPGF object status, review, release, listing, publication, correction, handoff, or archive. ### 3.2.5 No hidden agency, shared liability, or collapsed authority. DDPGF shall prohibit interpretation of triad coordination, shared object workflows, joint public-safe reporting, shared Registry references, Marketplace listings, Nexus Universe participation, Foundry builds, Studio workflows, Grid inputs, Reports publications, or handoff context packages as creating hidden agency, partnership by implication, joint venture, fiduciary duty, shared liability, public authority delegation, procurement authority, finance authority, certification authority, standards authority, or execution authority among The Global Centre for Risk and Innovation, The Global Risks Forum, The Global Risks Alliance, Nexus bodies, consortium bodies, public authorities, providers, sponsors, capital readers, insurers, communities, National Consortium Companies, Project SPVs, or lawful handoff recipients. Where an object involves multiple institutions, the object record shall identify the relevant roles, review responsibilities, boundary notices, and correction responsibilities. Silence shall not create authority. Participation shall not create control. Contribution shall not create validation. Stewardship shall not create warranty. Handoff shall not create execution. ## 3.3 Nexus Pillar Interfaces ### 3.3.1 Nexus Foundry. DDPGF shall interface with Nexus Foundry by governing the digital public-good objects produced through Foundry programs, tracks, quests, bounties, builds, micro-production, maintainer systems, quality gates, releases, and archives. Foundry shall use DDPGF to assign object identity, object class, metadata, license, support, review, Registry status, Marketplace eligibility, public-safe status, Grid input, TRL note, and handoff context to each digital output. Foundry outputs governed by DDPGF may include software, data pipelines, dashboards, Studio workflows, Marketplace objects, Registry records, Grid inputs, TRL evidence notes, National Portfolio objects, Reports artefacts, Campaign objects, and handoff dependency packages. Foundry production shall remain non-executing by default and shall not produce certification, procurement approval, financeability, public authority action, deployment authorization, or implementation authority by implication. ### 3.3.2 Nexus Marketplace. DDPGF shall interface with Nexus Marketplace by providing the object governance rules for listing, discovery, metadata display, support discovery, learning discovery, contribution opportunities, public-good distribution, demand signals, and handoff awareness. Marketplace shall list only DDPGF-governed objects or approved metadata derived from DDPGF-governed records. Marketplace shall preserve procurement neutrality, provider neutrality, sponsor-boundary discipline, finance-boundary discipline, public authority boundary discipline, public-safe communication, and correction/delisting pathways. Marketplace listing shall not imply endorsement, approval, validation, certification, procurement status, finance status, insurance status, handoff authorization, deployment authorization, or execution authority. ### 3.3.3 Nexus Registry. DDPGF shall interface with Nexus Registry by defining the lifecycle status, versioning, provenance, support status, review status, public-safe status, sensitivity class, correction history, withdrawal history, recall history, archive state, and boundary notices for every recordable digital public-good object. Registry shall be the status-truth surface for DDPGF objects, while DDPGF shall define the object governance logic that makes status truth meaningful, current, bounded, and correctionable. Registry shall not certify, approve, validate, rank, finance, insure, procure, or authorize deployment. Registry shall preserve truth of status within scope and shall update promptly when an object is corrected, downgraded, suspended, withdrawn, recalled, superseded, archived, or made non-continuing. ### 3.3.4 Nexus Studio. DDPGF shall interface with Nexus Studio by governing the software, data, model, AI-agent, API, dashboard, digital twin, simulation, notebook, secure-room, data-room, clean-room, compute-to-data, and controlled workflow objects used in Studio environments. Studio shall operate on DDPGF-governed objects according to access class, data-use label, AI-use label, sensitivity class, public-safe status, runtime controls, and output review rules. Studio workflows may produce public-safe summaries, Registry updates, Marketplace candidates, Reports artefacts, Grid inputs, TRL notes, National Portfolio updates, Nexus Universe demonstration records, and handoff context notes. Studio workflows shall not create deployment, public authority action, operational command, finance approval, insurance underwriting, procurement status, consent, or execution authority. ### 3.3.5 Nexus Grid. DDPGF shall interface with Nexus Grid by supplying the digital objects, metadata, evidence records, review records, support records, reproducibility records, public-safe records, correction records, and lifecycle states required for bounded readiness assessment. Grid shall classify readiness and maturity inputs within scope, while DDPGF shall preserve the object-level evidence, version, review, support, and correction basis underlying those inputs. Grid inputs and TRL records shall remain assurance without certification. A Grid status, readiness class, maturity input, or TRL note shall not create certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution authority. ### 3.3.6 Nexus Reports. DDPGF shall interface with Nexus Reports by governing publication artefacts, repository deposits, report packages, data availability statements, AI-use statements, metadata, public-safe abstracts, DOI-linked objects where applicable, licensing, support statements, correction notices, withdrawals, and archive records. Reports shall transform DDPGF-governed evidence and objects into public-safe knowledge products where publication is permitted. Reports publication shall remain bounded by DDPGF public-safe controls, protected knowledge controls, sensitivity controls, data-use labels, AI-use labels, no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-execution language, and correction pathways. ### 3.3.7 Nexus Campaigns. DDPGF shall interface with Nexus Campaigns by governing campaign pages, campaign dashboards, signature records, pledge records, support records, volunteer records, team records, chapter records, ambassador records, quest and bounty objects, campaign reports, Support Ledgers, public-safe storytelling objects, DICE contribution records, DRI contribution records, National Working Group formation records, Competence Cell formation records, Nexus Universe routing records, correction records, and archives. Campaign digital objects shall preserve trust and safety, fraud controls, sponsor controls, provider controls, public authority boundary controls, community consent boundary controls, data protection, public-safe communication, and no-conversion notices. Campaign activity shall not create vote, mandate, binding finance, donor commitment, employment, public authority approval, procurement status, community consent, Indigenous consent, deployment authorization, or execution authority. ### 3.3.8 Nexus Academy. DDPGF shall interface with Nexus Academy by governing learning objects, open educational resources, courses, modules, lessons, labs, Studio exercises, contribution tasks, quests, bounties, builds, capstones, portfolio artefacts, public-good software learning packages, data learning packages, AI-use learning packages, cyber and privacy learning packages, Marketplace and Registry learning packages, Grid and TRL learning packages, Nexus Universe preparation objects, and lawful handoff literacy materials. Academy learning objects shall preserve evidence basis, competency mapping, accessibility, translation, localization, public-safe status, review status, correction pathway, and archive rule. Learning availability or completion shall not create certification, professional license, employment, procurement eligibility, public authority competence, deployment authorization, or execution authority. ### 3.3.9 Risk Academy. DDPGF shall interface with Risk Academy by governing risk literacy objects, DRR learning objects, DRF literacy objects, DRI learning objects, WFEH-B learning objects, GRIx taxonomy objects, public-safe risk communication exercises, Observatory literacy objects, scenario learning objects, crisis-learning objects, after-action learning objects, public authority learning objects, safeguard literacy objects, finance-readiness literacy objects, insurance-readiness literacy objects, and handoff dependency literacy objects. Risk Academy outputs shall be public-safe, evidence-bearing, and correctionable within recorded scope. Risk Academy learning shall not create public warning authority, public authority decision authority, insurance underwriting, investment advice, disaster-risk rating, country ranking, professional license, certification, or execution authority. ### 3.3.10 Nexus Labs. DDPGF shall interface with Nexus Labs by governing research objects, research questions, evidence gaps, testbed records, method notes, dataset records, model cards, system cards, benchmark records, scenario records, public-safe summaries, research impact records, Foundry transfer records, repository packages, and controlled research outputs. Labs shall use DDPGF to move research from discovery to reusable public-good objects without collapsing research into approval, certification, deployment, or execution. Research objects shall be governed by research ethics boundaries, data rights, AI-use controls, public-safe publication, protected knowledge controls, community safeguards, public authority boundaries, sponsor and provider controls, dual-use controls, correction, and archive. ### 3.3.11 Risk Agency. DDPGF shall interface with Risk Agency by governing expert profiles, request records, matching records, expert standing records, conflict records, engagement records, output records, reliance labels, advisory memoranda, consultancy notes, training packs, workshop records, readiness question maps, risk interpretation notes, public-safe summaries, scenario learning records, dashboard literacy notes, handoff support notes, correction notices, and archive records. Risk Agency objects shall distinguish advisory support from execution. Expert matching shall not certify experts by default. Advisory outputs shall not create public authority decisions, investment advice, insurance underwriting, procurement recommendations, community consent, deployment authorization, or execution authority unless separately and lawfully recorded outside default DDPGF status. ### 3.3.12 Nexus Observatory. DDPGF shall interface with Nexus Observatory by governing Observatory nodes, hubs, regional cluster records, national dense Nexus core records, edge signals, sensor records, geospatial layers, Earth observation records, digital twin inputs, degraded-mode awareness records, indicator records, signal records, hotspot records, multi-hazard records, cascade records, public-safe Observatory outputs, DRI contribution records, and Observatory correction archives. Observatory objects shall be governed by sensitivity labels, geospatial masking, cyber sensitivity review, public-safe output review, data-use labels, AI-use labels, community and protected knowledge controls, public authority boundary notices, and no-surveillance boundaries. Observatory signals shall not constitute public warning, official map, surveillance authority, public authority decision, insurance score, investment signal, emergency command, or execution authority. ### 3.3.13 Nexus Universe. DDPGF shall interface with Nexus Universe by governing annual surge objects, arena records, room records, participation records, Core Build records, public authority learning records, readiness question records, support records, Marketplace listings, Registry updates, Reports, Campaign updates, Foundry continuation records, National Portfolio updates, Studio demonstration records, Grid inputs, TRL notes, handoff dependency notes, correction records, and archives. Nexus Universe shall use DDPGF to convert annual visibility into durable records, not authority. Nexus Universe attendance, demonstration, listing, sponsorship, provider participation, public authority presence, capital-reader presence, insurance-reader presence, media coverage, or public display shall not create endorsement, approval, certification, financeability, insurability, procurement status, consent, deployment authorization, or execution authority. ### 3.3.14 Nexus Rails. DDPGF shall interface with Nexus Rails by enabling governed routing of objects across Nexus pillars, mechanisms, national nodes, regional structures, global structures, repositories, Registry, Marketplace, Studio, Grid, Reports, Nexus Universe, National Portfolios, secure rooms, data rooms, and lawful handoff pathways. Nexus Rails shall preserve object identity, version, access class, sensitivity class, data-use label, AI-use label, support class, public-safe status, correction pathway, and archive rule during routing. Routing shall not create approval, certification, procurement status, financeability, public authority action, consent, deployment authorization, or execution authority. Rails shall move records, dependencies, context, and status, not implied authority. ### 3.3.15 Nexus Network. DDPGF shall interface with Nexus Network by preserving object memory, contributor memory, institutional memory, participation records, learning records, Registry records, Marketplace discovery records, Reports records, Foundry records, Campaign records, Studio records, Grid records, Observatory records, National Portfolio records, Nexus Universe records, correction records, and archive records across time. Nexus Network shall support continuity, discovery, reuse, correction, and institutional learning without converting network presence into approval, membership authority, endorsement, procurement status, finance status, public authority status, consent, deployment authorization, or execution authority. ## 3.4 Nexus Mechanism Interfaces ### 3.4.1 DICE. DDPGF shall interface with DICE as the governing bridge for Data Commons, Innovation Commons, Software Commons, Knowledge Commons, Guild Commons, secure rooms, data rooms, clean rooms, compute-to-data workflows, and public-good digital economy infrastructure. DICE shall provide the commons environment through which DDPGF objects are stored, accessed, governed, protected, transformed, published where safe, restricted where necessary, corrected, and archived. DICE shall preserve data minimization, purpose limitation, consent and permission, access control, cross-border controls, data sovereignty, localization, retention, deletion, sealing, archive, incident response, AI-use labels, and secure-room rules. DICE availability shall not create data rights, open data status, unrestricted reuse, public authority approval, handoff permission, automated decision authority, warranty, deployment authorization, or execution authority. ### 3.4.2 GRIx. DDPGF shall interface with GRIx as the risk ontology, controlled vocabulary, taxonomy, category, and semantic interoperability mechanism for Nexus risk meaning. GRIx objects shall provide categories for WFEH-B, DRR, DRF, DRI, systems risk, frontier technology risk, public authority boundaries, finance and insurance boundaries, safeguard categories, and handoff dependency categories. DDPGF shall govern GRIx ontology objects, schema objects, category records, mapping records, localization records, translation records, deprecation records, correction records, and archive records. GRIx categories shall not constitute legal classifications, ratings, standards adoption, public authority determinations, finance classifications, insurance classifications, procurement classifications, or execution authority. ### 3.4.3 DRI. DDPGF shall interface with DRI as the disaster risk intelligence mechanism for indicator records, signal records, confidence labels, uncertainty labels, public-safe intelligence summaries, dashboard records, hotspot records, multi-hazard records, cascade records, national DRI contributions, correction records, and archives. DRI objects shall be governed as risk intelligence objects, not warning or rating objects. DDPGF shall require DRI objects to carry public-safe controls, no-warning notices, no-rating notices, data-use labels, AI-use labels where applicable, source basis, method basis, uncertainty, confidence, sensitivity labels, correction pathways, and archive rules. DRI output shall not be treated as public warning, insurance score, investment signal, public authority decision, official risk rating, emergency command, or execution instruction. ### 3.4.4 Integrated Learning Account. DDPGF shall interface with the Integrated Learning Account by governing learner record objects, competency portfolio objects, skills wallet entries, learning achievement records, contribution records, evidence-of-learning records, competence pathway records, national learning records, safeguard learning records, public authority learning participation records, portability records, correction records, and archive records. ILA-linked objects shall preserve learner privacy, consent and permission, portfolio visibility, data-use rules, AI-use restrictions, youth and vulnerable learner protections, correction rights, withdrawal requests, and non-equivalence notices. ILA records shall not create employment, certification, professional license, immigration status, wage claim, procurement qualification, public authority credential, or execution authority. ### 3.4.5 Integrated Credits and Rewards System. DDPGF shall interface with the Integrated Credits and Rewards System by governing contribution recognition objects, learning credit records, contribution credit records, review credit records, mentor credit records, bounty recognition records, support-linked recognition records, non-monetary recognition objects, stipend or honorarium records where lawful, correction of credits, and contribution archive records. iCRS objects shall recognize contribution within recorded scope and shall not become currency, wage, compensation, equity, token, security, financial instrument, employment relationship, procurement qualification, credential by default, public authority status, or execution authority. DDPGF shall preserve contribution evidence, privacy, sponsor boundaries, provider boundaries, appeals, correction, withdrawal, and archive. ### 3.4.6 Work-Integrated Learning Paths. DDPGF shall interface with Work-Integrated Learning Paths by governing WILP records, learning agreements, workplans, mentor records, host records, supervision records, health and safety controls, safeguard controls, data and confidentiality controls, AI and tool-use controls, fair work controls, anti-exploitation controls, accessibility controls, grievance controls, portfolio artefacts, work product records, public-safe outputs, mentor verification, host verification, correction records, and archives. WILP objects shall support evidence-bearing learning through work without creating disguised labor, employment by implication, hiring commitment, deployment authorization, public authority decision, community consent, procurement status, or execution authority. DDPGF shall ensure WILP objects preserve labor boundaries and learner protections. ### 3.4.7 Micro-Production Model. DDPGF shall interface with the Micro-Production Model by governing micro-task objects, micro-bounty objects, micro-build objects, micro-review objects, micro-release objects, micro-correction objects, micro-archive objects, micro-production support classes, contribution records, review records, public-safe output records, and Registry or Marketplace routing records. Micro-production objects shall enable distributed, incremental, evidence-bearing public-good output without creating employment, procurement qualification, certification, product approval, deployment authorization, or execution authority. Micro-production support or reward records shall remain bounded by iCRS, labor boundary, sponsor boundary, provider boundary, and correction controls. ### 3.4.8 Integrated Value Reporting System. DDPGF shall interface with the Integrated Value Reporting System by governing value-reporting objects related to public-good value, learning value, contribution value, evidence value, risk-reduction value, resilience value, national capability value, support value, correction value, reuse value, accessibility value, localization value, and archive value. Value reporting shall support public-good accountability and system learning. Value reporting objects shall not constitute financial statements, valuations, investment advice, cost-benefit certification, public finance allocation, insurance underwriting, procurement scoring, country ranking, provider ranking, social scoring, or execution authorization. DDPGF shall ensure value records remain descriptive, bounded, evidence-bearing, and correctionable. ### 3.4.9 Proof Receipts. DDPGF shall interface with Proof Receipts by governing records that evidence occurrence of defined actions, submissions, reviews, contributions, publications, releases, corrections, access events, routing events, handoff steps, support events, or lifecycle transitions. Proof Receipts may link to Dockets, ILA, iCRS, WILPs, DICE, GRIx, DRI, Marketplace, Registry, Studio, Grid, Reports, Campaigns, Foundry, Nexus Universe, National Portfolios, and handoff packages. Proof Receipts shall prove recorded occurrence within scope, not substantive approval beyond scope. Proof Receipts shall not constitute certification, legal compliance, public authority approval, financeability, procurement status, consent, deployment authorization, or execution authority. ### 3.4.10 Dockets. DDPGF shall interface with Dockets by governing digital object candidates, issue records, need records, challenge briefs, evidence needs, data needs, software needs, model needs, research needs, learning needs, campaign needs, Studio workflow needs, Grid input needs, TRL note needs, Registry needs, Marketplace needs, Reports needs, National Portfolio needs, Nexus Universe needs, handoff needs, correction needs, and archive needs. Docketing shall create structured work visibility, not approval, funding, procurement, deployment, public authority action, or execution. DDPGF shall ensure Docket items carry purpose, scope, source class, sensitivity class, review needs, boundary notices, correction pathway, and archive or non-continuation options. ### 3.4.11 Support Ledgers. DDPGF shall interface with Support Ledgers by governing records of lawful support, sponsor support, donor support, provider support, host support, volunteer support, in-kind support, infrastructure support, software support, data support, translation support, accessibility support, campaign support, Foundry support, Academy support, Nexus Universe support, and handoff-context support. Support Ledger objects shall preserve transparency, anti-capture discipline, no pay-to-validate, no pay-to-prioritize, no sponsor control, no provider validation, and no hidden exclusivity. Support records shall not create ownership, procurement status, finance commitment, endorsement, public authority approval, certification, deployment authorization, or execution authority. ### 3.4.12 Assumptions Registers. DDPGF shall interface with Assumptions Registers by governing recorded assumptions associated with software, data, models, simulations, digital twins, dashboards, reports, DRI indicators, GRIx mappings, Studio workflows, Grid inputs, TRL notes, National Portfolios, finance-readiness questions, insurance-readiness questions, public authority learning, and handoff packages. Assumption records shall identify uncertainty, dependency, evidence basis, review needs, sensitivity, update triggers, correction pathways, and limitations. Assumptions shall not be treated as facts, approvals, forecasts, finance determinations, insurance determinations, public authority decisions, deployment authorizations, or execution commands. ### 3.4.13 Dependency Registers. DDPGF shall interface with Dependency Registers by governing dependencies among objects, systems, data, models, software packages, APIs, repositories, infrastructure, licenses, providers, support classes, national pathways, public authority decisions, legal requirements, community safeguards, Indigenous protocols where applicable, finance-readiness questions, insurance-readiness questions, procurement steps, and handoff recipients. Dependency records shall make prerequisites visible without satisfying them by implication. A recorded dependency shall not constitute approval, finance, insurance, procurement, consent, public authority decision, deployment authorization, or execution authority. Dependency closure shall require separate evidence and review. ### 3.4.14 Correction Registers. DDPGF shall interface with Correction Registers by governing corrections, errata, addenda, patches, revisions, supersessions, downgrades, suspensions, withdrawals, recalls, retractions where necessary, public repairs, archive actions, non-continuation records, and correction propagation across Registry, Marketplace, Reports, Studio, Grid, TRL, DICE, GRIx, DRI, Observatory, Foundry, Campaigns, Academy, Nexus Universe, National Portfolios, and handoff packages. Correction Registers shall preserve trust by making errors and changes visible. Correction shall not be treated as failure alone; it shall be a required governance function. Correction records shall not create new authority beyond the corrected scope. ### 3.4.15 Archive Registers. DDPGF shall interface with Archive Registers by governing archive objects, archive metadata, archive access classes, archive-not-current notices, historical use notes, successor links, correction history, license status, public-safe status, retention rules, non-continuation notes, withdrawal records, recall records, and preservation of institutional memory. Archive Registers shall prevent stale objects from being used as current authority while preserving traceability, learning, accountability, and correction history. Archive status shall not imply current validity, support, approval, certification, deployment readiness, or execution authority. ## 3.5 National and Regional Interfaces ### 3.5.1 Global Nexus Consortium. DDPGF shall interface with the Global Nexus Consortium as the global agenda, common rail, public-good records, standards-interface, Nexus Universe, acceleration, observability, and global-to-regional routing layer for digital public-good objects. The Global Nexus Consortium may help identify global digital public-good needs, common object families, cross-regional interoperability questions, public-safe reporting priorities, repository strategies, Nexus Universe object pathways, and global-to-regional support routes. The Global Nexus Consortium shall not, through DDPGF, create global supremacy, standards authority, certification authority, procurement authority, finance authority, public authority approval, provider validation, national bypass, or execution authority. DDPGF objects routed through the Global Nexus Consortium shall preserve national ownership, role separation, Registry status, Marketplace boundaries, public-safe controls, and correctionability. ### 3.5.2 Regional Nexus Consortiums. DDPGF shall interface with Regional Nexus Consortiums as regional cluster, translation, localization, country-support, systems-risk, Nexus Universe preparation, standards-localization, observability, acceleration, and finance-readiness support layers for digital public-good objects. Regional Nexus Consortiums may support regional object catalogues, regional language access, regional risk-intelligence objects, regional DRI and Observatory objects, regional Core Build needs, regional repository mirrors, regional training objects, and regional handoff-context preparation. Regional Nexus Consortiums shall not override national authority, collapse national ownership, certify objects, approve providers, control procurement, allocate finance, issue public warnings, or execute projects by default. Regional localization shall not create public authority adoption, standards adoption, legal equivalence, country ranking, consent, deployment authorization, or execution authority. ### 3.5.3 National Nexus Consortiums. DDPGF shall interface with National Nexus Consortiums as the normal country-level ownership and gateway layer for national Nexus digital public-good activity. National Nexus Consortiums may govern national routing of DDPGF objects, national repository mirrors, national language and legal-context localization, national data sovereignty controls, national public authority learning records, national safeguard records, national Marketplace listings, national Registry records, national Reports objects, national Studio workflows, national Grid inputs, national TRL notes, national Nexus Universe objects, and national handoff-context packages. National Nexus Consortiums shall not be treated as public authorities, procurement bodies, finance actors, insurers, certifiers, standards authorities, project developers, operators, or execution vehicles by default. National gateway status shall preserve national ownership and anti-bypass discipline without creating public authority action, procurement approval, financeability, insurability, certification, consent, deployment authorization, or execution authority. ### 3.5.4 National Nodes. DDPGF shall interface with National Nodes as localized operational surfaces for national digital public-good object governance, repository mirroring, access control, learning object distribution, data stewardship, public-safe reporting, Studio routing, Marketplace and Registry updates, Academy use, Campaign support, Foundry contribution, Observatory contribution, DRI contribution, and handoff context preparation. National Nodes shall preserve national context, language, accessibility, data sovereignty, public authority boundaries, community safeguards, Indigenous protocols where applicable, protected knowledge controls, and correction pathways. National Node operation shall not create public authority approval, deployment authorization, procurement status, financeability, provider validation, community consent, or execution authority. ### 3.5.5 National Working Groups. DDPGF shall interface with National Working Groups as work formation, evidence, competency, risk, data, software, policy-learning, public-safe reporting, Observatory, DRI, GRIx, Foundry, Campaign, Academy, Studio, Grid, Nexus Universe, and handoff-context contributors. National Working Groups may propose, review, adapt, localize, translate, test, document, and correct DDPGF objects within recorded scopes. National Working Group participation shall not create authority, endorsement, certification, public authority approval, procurement status, financeability, consent, deployment authorization, or execution authority. Working Group outputs shall become DDPGF objects only through recorded intake, classification, review, Registry status, public-safe controls, and correction pathways. ### 3.5.6 Nexus Competence Cells. DDPGF shall interface with Nexus Competence Cells as applied capability units that produce, review, localize, maintain, teach, test, and improve digital public-good objects. Competence Cells may work on data objects, software objects, AI objects, dashboards, ontology objects, DRI indicators, Observatory records, Studio workflows, Marketplace objects, Registry records, Reports artefacts, Grid inputs, TRL notes, National Portfolio objects, and handoff-context objects. Competence Cell work shall remain evidence-producing and learning-producing unless separately routed to lawful handoff. Competence Cell output shall not create certification, professional license, procurement qualification, public authority approval, financeability, deployment authorization, or execution authority. ### 3.5.7 National Councils. DDPGF shall interface with National Councils as stakeholder formation and participation surfaces that may identify national digital public-good needs, review public-safe priorities, shape participation records, propose Working Group formation, support National Portfolio object priorities, contribute public authority learning questions, identify learning needs, support Campaign objects, and route Nexus Universe preparation. National Council participation shall not create authority, board appointment, endorsement, public authority action, procurement status, financeability, certification, community consent, deployment authorization, or execution authority. DDPGF shall preserve Council inputs as participation records and Docket inputs unless and until they become reviewed digital objects through formal pathways. ### 3.5.8 Helix Councils. DDPGF shall interface with Helix Councils as sectoral and stakeholder-specific participation surfaces across government/public authority, academia/research/science, industry/enterprise/infrastructure/technology, capital/insurance/donor/development, media/civic/public-interest, and community/Indigenous/diaspora/place-based legitimacy contexts. Helix Councils may identify object needs, domain language, data sensitivity, technical standards questions, public-safe reporting needs, workforce needs, safeguard concerns, support opportunities, and handoff dependencies. Helix Council inputs shall not create certification, approval, procurement status, financeability, public authority action, consent, provider validation, sponsor control, deployment authorization, or execution authority. DDPGF shall record Helix Council contributions within role-specific boundaries and route them to Dockets, Working Groups, Competence Cells, Foundry, Academy, Campaigns, Reports, Studio, Grid, Nexus Universe, or handoff-context review as appropriate. ### 3.5.9 National Consortium Companies. DDPGF shall interface with National Consortium Companies as legally separate enterprise-stack vehicles that may receive lawful handoff context, contribute support, host infrastructure, support localization, provide implementation feedback, operate repositories or environments under agreement, or become downstream recipients of DDPGF handoff packages where lawful. National Consortium Companies shall remain separate from public-good consortium governance and from DDPGF object authority. A DDPGF object routed to a National Consortium Company shall transfer context, dependencies, evidence, data-use conditions, AI-use conditions, support status, safeguards, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, correction pathways, and recall pathways. Such routing shall not create procurement award, finance approval, insurance approval, public authority approval, certification, consent, deployment authorization, or execution by Nexus. ### 3.5.10 Project SPVs. DDPGF shall interface with Project SPVs as legally separate project-specific enterprise-stack vehicles that may receive lawful handoff context, implementation dependency packages, evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status notes, safeguard notes, public authority dependency notes, legal dependency notes, finance and insurance question notes, provider-neutrality notes, sponsor-boundary notes, recipient responsibility notes, correction pathways, and recall pathways. A Project SPV shall be responsible for its own lawful diligence, authority, finance, insurance, procurement, permits, approvals, community engagement, Indigenous protocols where applicable, data rights, deployment, operation, and execution. DDPGF shall not convert handoff to a Project SPV into certification, approval, procurement status, financeability, insurability, consent, deployment authorization, or Nexus execution. --- # 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/iii.-interfaces.md?ask= ``` 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.