# IV. SOFTWARE

## 4.1 Software Commons Doctrine

### 4.1.1 Public-good software defined.

Public-good software under DDPGF means software that is created, adapted, maintained, reviewed, documented, released, listed, recorded, or archived for public-good use within Nexus and that is governed as a reusable digital public-good object rather than as an uncontrolled product, private platform asset, procurement instrument, finance asset, regulatory tool, or execution vehicle. Public-good software may include repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, adapters, command-line tools, notebooks, templates, infrastructure-as-code, test suites, reference implementations, reproducibility packages, model-support code, data-pipeline code, Studio workflow code, Registry and Marketplace components, Observatory components, DRI components, GRIx components, Nexus Universe components, National Portfolio components, and lawful handoff support components.

Public-good software shall be defined by its recorded purpose, object identity, steward, version, source pathway, license class, support class, review status, public-safe status, security status, access class, correction pathway, archive rule, and no-conversion notices. It may be open, controlled, restricted, secure-room-only, data-room-only, Studio-only, national-node-only, or handoff-recipient-only depending on classification, rights, safeguards, cybersecurity, privacy, protected knowledge, public authority sensitivity, and lawful handoff boundaries. Software shall not be treated as public-good software merely because it is published, shared, open-source, free of charge, sponsor-supported, provider-contributed, publicly visible, or used in a Nexus context; it shall become DDPGF-governed public-good software only when it is recorded, classified, reviewed, and governed under DDPGF lifecycle rules.

### 4.1.2 Open technical baseline defined.

An open technical baseline means a documented, reusable, reviewed, and correctionable technical foundation that enables interoperability, reproducibility, public-good learning, national localization, public-safe reuse, and lawful handoff context without creating certification, procurement approval, provider preference, standards authority, deployment authorization, or execution authority. An open technical baseline may include reference architectures, repository structures, schemas, APIs, SDKs, data pipelines, model-support utilities, dashboard templates, Observatory components, DRI indicator tooling, GRIx taxonomy tooling, Studio workflow patterns, Grid input templates, TRL evidence note templates, report package tooling, secure-room workflow patterns, compute-to-data patterns, testing harnesses, documentation patterns, deployment-neutral configuration examples, and public-safe release packages.

Open technical baselines shall be designed to reduce duplication, increase transparency, improve learning, support national capability formation, preserve interoperability, and allow lawful actors to understand dependencies before implementation. They shall not create exclusive vendor channels, implicit conformance marks, public authority approval, operational readiness claims, finance-readiness claims, insurance-readiness claims, or procurement preference. Any actor using an open technical baseline for downstream implementation shall remain responsible for its own diligence, security, legal compliance, operational validation, public authority approvals, procurement processes, community and Indigenous protocols where applicable, data rights, deployment controls, maintenance, and execution.

### 4.1.3 Reference implementation defined.

A reference implementation means a software object or software package that demonstrates how a method, schema, API, protocol object, data pipeline, model workflow, Studio workflow, DRI indicator, GRIx mapping, Observatory component, secure-room workflow, compute-to-data pattern, Registry record, Marketplace listing, Reports package, Grid input, TRL evidence note, proof receipt, or handoff package may be implemented within a defined scope. A reference implementation shall be treated as an evidence-bearing example, not as the only permitted implementation, not as a production-ready product by default, not as a certified system, and not as an approved operational tool.

Every reference implementation shall carry an object record stating its intended use, prohibited uses, assumptions, dependencies, configuration limits, data requirements, security limits, privacy limits, support class, test status, review status, known issues, correction pathway, archive rule, and no-warranty/no-deployment/no-procurement/no-certification notices. Where a reference implementation is adapted by national nodes, providers, public authorities, National Consortium Companies, Project SPVs, universities, laboratories, or other lawful actors, the adapted version shall receive its own version record, localization record, dependency record, and correction pathway. The existence of a reference implementation shall not prevent alternative implementations, provided they respect applicable DDPGF object governance, public-good stack boundaries, rights, safeguards, interoperability requirements, and correction obligations.

### 4.1.4 Public-good code without warranty.

Public-good code shall be released, shared, displayed, listed, demonstrated, or handed off only with clear support-class and no-warranty discipline unless a separate written agreement lawfully creates a different obligation. A software object may be useful, reviewed, tested, reusable, well-documented, security-scanned, public-safe, Marketplace-listed, Registry-recorded, Studio-ready, Grid-routed, or TRL-noted, but none of those statuses shall create an implied warranty, service-level commitment, fitness-for-purpose assurance, professional assurance, cybersecurity certification, operational guarantee, business-continuity guarantee, or liability assumption.

The default DDPGF rule shall be that software is provided as a public-good object within recorded scope and subject to correction, withdrawal, recall, deprecation, suspension, supersession, archive, and non-continuation. Users and downstream recipients shall remain responsible for independent review, configuration, security hardening, privacy assessment, data rights review, accessibility review, legal review, public authority dependency review, procurement compliance, operational validation, integration testing, maintenance planning, incident response, and execution decisions. Support status shall describe available support, not guarantee outcomes.

### 4.1.5 Software as evidence-bearing object.

Software under DDPGF shall be governed as an evidence-bearing object. Its value shall arise not only from functionality, but from the record of how it was created, reviewed, tested, documented, classified, licensed, supported, corrected, and archived. Each software object shall, where applicable, maintain evidence records for source pathway, authorship, contribution history, maintainer standing, dependencies, SBOM, license review, code review, tests, security scans, vulnerability disclosures, threat-model notes, accessibility review, reproducibility review, public-safe documentation, release notes, issue records, correction records, and archive status.

Software evidence shall support learning, reuse, technical review, public-good accountability, interoperability, National Portfolio memory, Nexus Universe readiness, Studio workflow preparation, Grid input, TRL evidence notes, Reports publication, Marketplace discovery, Registry status truth, and lawful handoff context. Evidence-bearing status shall not mean that the software is approved for production, certified, safe for all contexts, legally compliant in all jurisdictions, ready for procurement, financeable, insurable, public-authority-approved, or deployment-authorized. Evidence shall make claims reviewable; it shall not convert claims into authority.

### 4.1.6 Software as reusable learning object.

DDPGF software may function as a reusable learning object for Nexus Academy, Risk Academy, WILPs, ILA records, iCRS contribution recognition, micro-production pathways, Foundry contributor onboarding, Competence Cell training, National Working Group training, Studio exercises, secure-room practice, Observatory literacy, DRI indicator literacy, GRIx ontology literacy, public-safe reporting exercises, and lawful handoff literacy. Software learning reuse shall include documentation, examples, notebooks, exercises, test cases, contributor guides, maintainer guides, issue templates, review checklists, accessibility notes, security notes, and public-safe interpretation notes.

Use of software as a learning object shall not create professional certification, employment qualification, procurement eligibility, public authority competence, operational authority, deployment approval, provider validation, or execution authority. Learning status shall be recorded separately from software release status. A learner may receive a learning record, contribution record, review record, WILP record, micro-credential record, or iCRS recognition record based on software-related activity only within the applicable SCF, Academy, WILP, ILA, iCRS, and credential governance rules.

### 4.1.7 Software as Studio-ready component.

Software may be classified as Studio-ready where it has been reviewed and prepared for controlled runtime use in Nexus Studio, including dashboards, simulations, digital twins, AI workflow review, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader room workflows, insurance-reader room workflows, Nexus Universe workflows, and handoff demonstration workflows. Studio-ready classification shall require recorded access controls, runtime assumptions, data-use labels, AI-use labels, output review rules, logging expectations, no-write-back rules, no-command rules, data export restrictions, public-safe restrictions, shutdown triggers, correction triggers, and archive rules where applicable.

Studio-ready software shall not be treated as deployment-ready software by default. A software component may be suitable for controlled demonstration, simulation, review, training, or learning while remaining unsuitable for production, operational command, public authority action, finance decisioning, insurance underwriting, emergency management, field deployment, or enterprise execution. Studio-readiness shall be a bounded runtime classification, not certification, procurement readiness, public authority approval, financeability, insurability, deployment authorization, or execution authority.

### 4.1.8 Software as handoff context, not deployment authority.

Software governed under DDPGF may be included in lawful handoff packages as context, dependency, reference implementation, reusable component, evidence record, method support, data-processing aid, dashboard support, Studio artefact, Grid input, TRL note, or implementation-dependency note. Such handoff shall transfer information, dependencies, evidence, assumptions, limitations, support status, review status, public-safe status, security notes, data-use constraints, AI-use constraints, license terms, safeguard conditions, public authority dependencies, legal dependencies, correction pathways, and recall pathways.

Software handoff shall not transfer authority. A handoff recipient, including a public authority, provider, operator, contractor, funder, insurer, donor, university, lab, National Consortium Company, Project SPV, community actor, or other lawful actor, shall remain responsible for its own authority, legal review, procurement process, finance process, insurance process, public authority approvals, permits, licenses, community engagement, Indigenous protocols where applicable, cybersecurity, privacy, data rights, operational testing, deployment, maintenance, incident response, and execution. DDPGF software may support lawful implementation; it shall not authorize it.

## 4.2 Software Object Classes

### 4.2.1 Repositories.

Repositories shall be governed as the primary source-control and object-memory environments for DDPGF software. A repository may contain source code, documentation, tests, configuration, notebooks, schemas, APIs, templates, release notes, license files, contribution records, issue records, changelogs, security notices, SBOMs, model-support artefacts, data-pipeline artefacts, public-safe summaries, and archive records. Each repository shall have a repository steward, maintainer standing records, contribution rules, license class, access class, support class, security disclosure route, public-safe documentation status, correction pathway, and archive rule.

Repository creation shall not itself create public release, open-source status, Marketplace listing, Registry approval, production readiness, provider validation, procurement status, or deployment authorization. Repository access may be open, controlled, restricted, secure-room-only, internal, national-node-only, handoff-recipient-only, or archived depending on classification. Repository status shall be kept current in the Registry where the repository is a recorded DDPGF object.

### 4.2.2 Libraries.

Libraries shall be governed as reusable software components that provide functions, utilities, domain methods, data processing, model support, interface support, visualization support, observability support, risk intelligence support, secure-room support, compute-to-data support, or other reusable technical capability. Each library shall carry clear versioning, dependency records, license class, API documentation, intended-use statement, prohibited-use statement where needed, test status, security status, support class, and correction pathway.

Library reuse shall require attention to compatibility, dependency health, security, licensing, data rights, AI-use restrictions, jurisdictional context, and public-safe limitations. A library may support Foundry builds, Studio workflows, Reports packages, Academy learning, DICE workflows, Observatory workflows, DRI tooling, GRIx tooling, Marketplace objects, Registry records, Grid inputs, TRL notes, and handoff packages. Library availability shall not create warranty, certification, procurement recommendation, deployment authorization, or execution authority.

### 4.2.3 Services.

Services shall be governed as software components that provide network-accessible or environment-accessible functionality, including APIs, processing services, metadata services, dashboard services, authentication-adjacent services, data transformation services, model inference services, Observatory services, Registry services, Marketplace services, Reports services, Studio services, DRI services, GRIx services, or workflow orchestration services. Each service shall require service identity, purpose, scope, access controls, authentication and authorization model, logging rules, rate limits where applicable, data-use labels, AI-use labels where applicable, support class, continuity expectations, incident response pathway, shutdown triggers, correction pathway, and archive or decommissioning plan.

A service made available through DDPGF shall not create service-level warranty by default. Service availability, uptime, or operational status shall be descriptive unless a separate lawful agreement states otherwise. Service use shall not create data rights, public authority action, procurement status, financeability, insurance approval, deployment authorization, or execution authority.

### 4.2.4 Applications.

Applications shall be governed as user-facing or workflow-facing software objects that assemble functions, interfaces, workflows, data, APIs, dashboards, forms, models, repositories, or services into usable environments. Applications may support Academy learning, Campaigns, Foundry builds, DICE workflows, Studio workflows, Reports, Marketplace, Registry, Grid, Observatory, DRI, GRIx, Nexus Universe, National Portfolios, secure-room work, or handoff context.

Each application shall require recorded purpose, user classes, access class, data-use labels, AI-use labels, public-safe status, security review status, privacy review status, accessibility review status, support class, dependency records, release class, correction pathway, and archive rule. Application release shall not imply operational approval, public authority approval, procurement preference, vendor validation, financeability, insurability, deployment authorization, or execution authority.

### 4.2.5 Dashboards.

Dashboards shall be governed as visual interface software objects that display data, indicators, signals, metrics, maps, timelines, status records, portfolio objects, DRI objects, Observatory objects, Campaign objects, Foundry objects, Reports objects, Marketplace objects, Registry objects, Studio objects, Grid inputs, TRL notes, or handoff dependencies. Dashboards shall require source notes, update cadence, confidence labels, uncertainty labels where applicable, sensitivity review, geospatial review where applicable, public-safe labels, accessibility review, correction pathway, and archive rule.

Dashboards shall support interpretation, learning, monitoring, review, public-safe reporting, and decision support within boundaries. A dashboard shall not be a decision, warning, rating, forecast certainty, operational command, country ranking, provider validation, public authority record by default, insurance score, investment signal, procurement score, or deployment authorization.

### 4.2.6 APIs.

APIs shall be governed as interface objects that enable controlled access to data, metadata, software functions, Registry records, Marketplace listings, Studio workflows, Campaign objects, Reports objects, DRI indicators, GRIx categories, Observatory signals, Grid inputs, TRL notes, learning records, proof receipts, or handoff package objects. APIs shall require versioning, authentication, authorization, data minimization, rate limits where applicable, logging, abuse prevention, public-safe output filtering, deprecation notices, support class, security review, documentation, and correction pathway.

API availability shall not create data rights, unrestricted access, provider validation, standards conformance, procurement status, public authority approval, financeability, insurability, deployment authorization, or execution authority. API contracts shall remain bounded technical interfaces unless separately adopted by competent legal or standards authority outside DDPGF default posture.

### 4.2.7 SDKs.

SDKs shall be governed as developer-support software objects that enable lawful users, contributors, national nodes, Competence Cells, Foundry builders, Academy learners, Studio users, and handoff recipients to interact with DDPGF APIs, repositories, services, dashboards, data objects, model objects, Registry objects, Marketplace objects, Reports packages, Observatory objects, DRI objects, GRIx objects, and Studio workflows. SDKs shall require versioning, documentation, sample code, test coverage, dependency records, license class, security review, support class, and correction pathway.

SDK release shall not imply that downstream applications using the SDK are approved, secure, compliant, production-ready, interoperable in all settings, certified, procurement-ready, financeable, insurable, or deployment-authorized. SDK users remain responsible for downstream integration, rights, safeguards, security, privacy, testing, operational review, and lawful implementation.

### 4.2.8 Connectors.

Connectors shall be governed as software objects that connect DDPGF systems or objects to external systems, repositories, data sources, tools, clouds, national repositories, secure rooms, observability systems, dashboards, APIs, learning systems, credential systems, public authority learning systems, provider systems, or lawful handoff recipient systems. Connectors shall require source and destination records, data-flow notes, access controls, authentication and authorization rules, data-use labels, AI-use labels where applicable, provider-neutrality notes, privacy review, security review, public-safe output rules, logging, correction pathway, and deprecation plan.

Connector availability shall not validate the connected provider, certify the external system, create data rights, authorize data transfer, approve public authority use, grant procurement status, or authorize deployment. Connectors shall be disabled, restricted, suspended, corrected, or withdrawn where security, privacy, rights, safeguards, or boundary risks require action.

### 4.2.9 Adapters.

Adapters shall be governed as software objects that translate, map, transform, normalize, or bridge data formats, schemas, APIs, protocols, models, taxonomies, dashboards, workflow states, or repository structures across DDPGF contexts. Adapters may support semantic interoperability, national localization, standards-interface mapping, Studio workflows, Registry import/export, Marketplace listing, DICE workflows, DRI dashboards, GRIx mappings, Observatory inputs, and lawful handoff packages.

Adapters shall require mapping records, transformation logic, assumptions, limitations, version compatibility, data-use labels, public-safe review where outputs are visible, test status, correction pathway, and archive rule. Adapter use shall not create legal equivalence, standards adoption, certification, public authority approval, data right, provider validation, procurement readiness, or deployment authorization.

### 4.2.10 Command-line tools.

Command-line tools shall be governed as executable software objects intended for technical users, maintainers, contributors, national nodes, Competence Cells, Foundry builders, Studio operators, secure-room users, data stewards, or handoff recipients. Command-line tools may support repository operations, data processing, metadata generation, schema validation, model evaluation, dashboard generation, DRI processing, GRIx mapping, Observatory processing, report packaging, Registry updates, Marketplace preparation, Grid inputs, TRL notes, proof receipts, or archive workflows.

Command-line tools shall require documentation, usage constraints, permissions, safe defaults, logging where appropriate, dry-run or validation options where feasible, input/output classification, security review, dependency review, and correction pathway. Command-line tools shall not include operational command authority by implication and shall not be used to control external systems, public authority operations, infrastructure, emergency response, or deployment unless separately and lawfully authorized outside DDPGF default posture.

### 4.2.11 Notebooks.

Notebooks shall be governed as reproducibility, analysis, learning, demonstration, simulation, or review objects that combine code, text, data references, visualizations, assumptions, methods, outputs, and public-safe interpretation notes. Notebooks may support Academy learning, Risk Academy literacy, Labs research, Foundry builds, DICE workflows, DRI analysis, GRIx mapping, Observatory analysis, Studio demonstrations, Reports packages, Grid inputs, TRL notes, National Portfolio work, and handoff context.

Notebooks shall require source records, environment records, dependency records, data-use labels, AI-use labels where applicable, output review, public-safe transformation where needed, reproducibility review, security review where executable code is included, correction pathway, and archive rule. Notebook outputs shall not be treated as decisions, warnings, certifications, approvals, forecasts, finance determinations, insurance determinations, procurement recommendations, deployment authorizations, or execution instructions.

### 4.2.12 Templates.

Templates shall be governed as reusable software or document-structured objects that support consistent creation of DDPGF records, repositories, metadata, README files, license notices, contribution guides, model cards, system cards, benchmark cards, dataset cards, API cards, dashboard cards, Studio workflows, Registry records, Marketplace listings, Reports packages, Grid inputs, TRL evidence notes, proof receipts, correction notices, archive records, handoff packages, and public-safe notices.

Templates shall promote consistency without creating substantive approval. Template completion shall not by itself satisfy review, evidence, security, privacy, public-safe, safeguard, legal, finance, procurement, public authority, or handoff requirements. Each completed template shall require independent classification, review, and record status within the applicable DDPGF workflow.

### 4.2.13 Infrastructure-as-code.

Infrastructure-as-code objects shall be governed as software objects that describe or provision cloud, edge, HPC, sovereign compute, storage, secure enclave, network, observability, Studio runtime, secure-room, data-room, compute-to-data, repository, or platform environments. Infrastructure-as-code shall require provider-neutrality review, security review, identity and access management review, least-privilege review, data residency review, cost and support record, logging and monitoring expectations, continuity planning, teardown rules, and archive rules.

Infrastructure-as-code availability shall not approve a provider, validate an architecture for production, create public authority approval, authorize data hosting, grant data rights, satisfy procurement, create financeability, guarantee service levels, or authorize deployment. Any lawful actor using infrastructure-as-code for implementation shall remain responsible for configuration, compliance, security hardening, cost control, operational monitoring, incident response, public authority approvals, and execution.

### 4.2.14 Test suites.

Test suites shall be governed as software objects that support review, validation within scope, reproducibility, regression detection, conformance-question exploration, security assurance, accessibility checks, data quality checks, model evaluation, API compatibility, dashboard quality, Studio workflow testing, Grid evidence preparation, TRL evidence notes, and release governance. Test suites shall require scope statements, assumptions, expected inputs, expected outputs, coverage notes, limitations, version compatibility, dependency records, and correction pathway.

Passing a test suite shall not create certification, security approval, public authority approval, standards conformance, procurement readiness, financeability, insurability, deployment authorization, or general validation beyond the scope of the test. Test results shall be evidence inputs, not final authority.

### 4.2.15 Reference implementations.

Reference implementations shall be governed as demonstrative, reusable software packages showing one way to implement an approved method, schema, API, protocol object, data workflow, model workflow, dashboard pattern, Studio workflow, Registry workflow, Marketplace workflow, Reports package, Grid input, TRL evidence note, proof receipt, or handoff package. Reference implementations shall include purpose, scope, assumptions, dependencies, license, support class, security status, test status, known limitations, intended-use notes, prohibited-use notes where required, correction pathway, and archive rule.

Reference implementations may be reused for learning, experimentation, Studio demonstration, national localization, Foundry builds, Reports packages, and handoff context. They shall not be treated as production approval, exclusive implementation, certified architecture, procurement recommendation, provider validation, public authority tool, financeable asset, insurable asset, deployment authorization, or execution vehicle.

## 4.3 Software Lifecycle

### 4.3.1 Software intake.

Software intake shall be the first formal DDPGF lifecycle step through which a proposed software object is identified, described, classified, and routed. Intake shall record the software purpose, problem statement, source pathway, proposed steward, contributors, intended users, expected object class, license concerns, data-use implications, AI-use implications, security sensitivity, privacy implications, public-safe implications, safeguard concerns, public authority dependencies, provider or sponsor involvement, national or regional relevance, potential Studio use, Marketplace relevance, Registry relevance, Reports relevance, Grid or TRL relevance, and handoff relevance.

No software object shall proceed from intake to active build, public listing, public release, Studio use, Reports publication, Grid input, TRL note, or lawful handoff context unless its intake record has been completed to the level appropriate for its risk and use class. Intake shall create visibility and routing, not approval, warranty, certification, procurement status, financeability, deployment authorization, or execution authority.

### 4.3.2 Repository creation.

Repository creation shall establish the controlled source environment for a software object. The repository record shall identify object name, repository location, access class, steward, maintainer roles, contribution rules, license status, code of conduct, branch or release policy, issue-management model, security disclosure pathway, documentation requirements, testing expectations, dependency review approach, public-safe documentation rules, correction pathway, and archive rule.

Repository creation shall be role-separated from release approval. A repository may be created for concept, draft, internal review, controlled collaboration, secure-room review, public-good development, or archive purposes without creating public release status. Repository creation shall not imply that code is reviewed, safe, supported, open, endorsed, production-ready, deployable, or lawful for downstream implementation.

### 4.3.3 License selection.

License selection shall determine the legal use conditions for a software object within DDPGF. License review shall consider software license compatibility, open-source license requirements, contributor rights, third-party dependencies, attribution obligations, copyleft implications, patent-sensitive issues, data license interactions, model license interactions, documentation license interactions, restricted-use requirements, public-good continuity needs, sponsor or provider contribution boundaries, protected knowledge exclusions, national localization needs, and handoff constraints.

License selection shall be recorded before public release unless a controlled or restricted classification permits delayed external release. A license shall not create warranty, endorsement, certification, support obligation, procurement eligibility, public authority approval, financeability, deployment authorization, or unrestricted right to use related data, models, documentation, trademarks, names, or protected knowledge. License records shall be updated where dependencies, contributions, rights, restrictions, or downstream use conditions change.

### 4.3.4 Contribution model.

The contribution model shall define how contributors may propose, submit, review, revise, document, test, translate, localize, maintain, or correct software. Contribution rules shall include contributor eligibility, contribution pathways, code review rules, documentation rules, issue submission rules, security disclosure rules, AI-assisted contribution disclosure where required, data-handling restrictions, protected knowledge restrictions, attribution rules, conflict rules, sponsor and provider controls, public-safe communication rules, and correction pathways.

Contribution shall not create employment, compensation, ownership, maintainer standing, certification authority, provider validation, sponsor control, procurement qualification, or execution authority by implication. Contributions may create contribution records, iCRS records, ILA records, WILP records, learning records, review records, maintainer eligibility records, or public-good value records only through the applicable governance pathway.

### 4.3.5 Maintainer assignment.

Maintainer assignment shall designate individuals, teams, Competence Cells, Working Groups, institutional units, or authorized stewards responsible for repository care, issue triage, release preparation, review coordination, documentation quality, security channels, dependency monitoring, correction handling, deprecation planning, and archive readiness. Maintainer standing shall be recorded, reviewed, renewed, downgraded, suspended, or removed according to DDPGF governance rules.

Maintainer status shall not create ownership, employment, certification authority, procurement authority, public authority authority, provider validation, sponsor control, or deployment authority. Maintainers shall act within recorded scope and shall escalate legal, security, privacy, public-safe, safeguard, public authority, finance, procurement, or handoff boundary issues to the appropriate review pathway.

### 4.3.6 Dependency review.

Dependency review shall examine third-party libraries, packages, services, APIs, infrastructure components, models, data sources, licenses, vulnerabilities, maintainability risks, provenance risks, supply-chain risks, operational dependencies, provider dependencies, support dependencies, national hosting dependencies, and handoff dependencies. Dependency review shall produce dependency records, risk notes, update requirements, replacement recommendations, security findings, license findings, and correction triggers where applicable.

Dependency approval within DDPGF shall be bounded to the object and review scope. It shall not certify the dependency, validate the provider, approve procurement, guarantee security, guarantee continuity, create deployment authorization, or satisfy downstream legal or operational diligence. Dependency records shall be updated when vulnerabilities, license changes, support changes, abandonment, compromise, or compatibility issues arise.

### 4.3.7 Security review.

Security review shall assess code risks, dependency risks, secret exposure, authentication and authorization patterns, input validation, data handling, logging, encryption where appropriate, secure defaults, configuration risks, infrastructure risks, API risks, prompt-injection risks where AI is involved, supply-chain risks, vulnerability disclosure readiness, and incident response pathways. The review level shall be proportional to object sensitivity, access class, runtime class, public exposure, data class, AI-use class, public authority sensitivity, and handoff relevance.

Security review shall produce security records, not certification. A security-reviewed object may still contain unknown vulnerabilities, configuration risks, misuse risks, or downstream implementation risks. Security status shall not create security certification, production approval, procurement readiness, public authority approval, financeability, insurability, deployment authorization, or warranty.

### 4.3.8 Public-safe documentation.

Public-safe documentation shall describe software purpose, scope, intended users, intended uses, prohibited uses where required, installation or access instructions, configuration notes, data requirements, AI-use limits, security considerations, privacy considerations, public-safe limits, known issues, support status, license, attribution, contribution model, correction pathway, archive rule, and no-conversion notices. Documentation shall avoid language implying certification, official approval, public authority decision, procurement preference, financeability, insurance approval, deployment authorization, emergency command, or execution authority.

Where software relates to disaster risk, public health, cybersecurity, geospatial data, critical infrastructure, protected knowledge, communities, Indigenous protocols, public authority learning, finance-readiness, insurance-readiness, or handoff contexts, public-safe documentation shall include appropriate sensitivity controls, uncertainty statements, boundary notices, and escalation pathways. Documentation shall be corrected when software status, limitations, vulnerabilities, dependencies, support, public-safe status, or release class changes.

### 4.3.9 Release classification.

Release classification shall determine the permitted distribution and use status of a software object. Release classes may include concept, draft, internal review, sandbox, Studio-only, secure-room-only, data-room-only, controlled public, open public, Marketplace candidate, Registry-recorded, handoff-recipient-only, suspended, withdrawn, archived, or non-continuing. Classification shall consider purpose, review status, security status, license status, data-use implications, AI-use implications, public-safe status, safeguard status, public authority sensitivity, provider or sponsor involvement, national routing, and handoff relevance.

A release classification shall describe distribution status, not universal fitness. Open public release shall not imply unrestricted operational use. Controlled release shall not imply approval. Studio-only release shall not imply deployment readiness. Handoff-recipient-only release shall not imply execution authority. Release class shall be recorded in the Registry where applicable and reflected in Marketplace listings, Reports packages, Studio workflows, Grid inputs, TRL notes, and handoff packages.

### 4.3.10 Marketplace listing.

Marketplace listing shall make a software object discoverable within approved public-good or controlled discovery boundaries. Listing shall require object metadata, steward information, version, license class, support class, review status, Registry status, public-safe status, access class, intended-use summary, limitations, correction pathway, archive rule, and boundary notices. Listing governance shall include metadata review, public-safe review, license review, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, and delisting triggers.

Marketplace listing shall not create procurement recommendation, endorsement, validation, certification, provider approval, public authority approval, financeability, insurability, deployment authorization, or execution authority. Featured placement, high reuse, download activity, campaign attention, sponsor support, provider contribution, or Nexus Universe visibility shall not alter this rule.

### 4.3.11 Registry record.

A Registry record shall preserve the status truth of a software object. It shall include object identity, version, steward, source pathway, repository reference where appropriate, license class, support class, review status, access class, public-safe status, sensitivity class, release class, dependency record references, security status, correction history, withdrawal history, recall history, deprecation status, archive status, and boundary notices. The Registry record shall be updated when the software is modified, reviewed, released, listed, supported, unsupported, corrected, downgraded, suspended, withdrawn, recalled, superseded, deprecated, archived, or made non-continuing.

Registry record existence shall not create certification, endorsement, procurement status, warranty, legal compliance, public authority approval, financeability, insurance approval, deployment authorization, or execution authority. Registry status shall remain bounded, current, correctionable, and subordinate to the recorded evidence.

### 4.3.12 Support classification.

Support classification shall identify what level of support, if any, applies to the software object. Support classes may include unsupported public release, community-supported, maintainer-supported, Academy-supported, Foundry-supported, National Node-supported, Studio-supported, handoff-recipient-supported, time-limited support, security-only support, deprecated support, archived support, or no-support. The support class shall specify expected channels, response posture, known limitations, maintenance expectations, dependency monitoring expectations, and correction pathway.

Support classification shall not create warranty, service-level agreement, operational guarantee, cybersecurity guarantee, professional assurance, procurement status, financeability, deployment authorization, or execution authority. Any higher support obligation shall require a separate written agreement, recorded separately from default DDPGF support class.

### 4.3.13 Correction.

Correction shall be a required lifecycle function for DDPGF software. Correction may include patch, erratum, addendum, revision, documentation update, dependency update, security fix, configuration warning, public-safe notice, Registry update, Marketplace update, Reports correction, Studio workflow update, Grid update, TRL note update, handoff recall, suspension, withdrawal, supersession, deprecation, archive, or non-continuation. Correction triggers may include errors, vulnerabilities, dependency failures, license issues, public-safe concerns, privacy incidents, AI incidents, cyber incidents, protected knowledge issues, provider validation overclaims, sponsor control risks, public authority boundary incidents, finance boundary incidents, procurement boundary incidents, consent overclaims, handoff overclaims, or execution overclaims.

Correction shall be documented and propagated to affected records, listings, reports, workflows, packages, and recipients. Correction shall preserve trust and institutional memory. Correction shall not by itself create certification, approval, warranty, or new authority beyond the corrected record.

### 4.3.14 Deprecation.

Deprecation shall identify software that remains available within limits but should no longer be used for new work except where explicitly permitted. Deprecation records shall state the reason, effective date, affected versions, successor object where applicable, migration guidance, support status, security implications, public-safe implications, handoff implications, correction history, and archive plan.

Deprecated software shall not be presented as current, recommended, certified, supported beyond its support class, procurement-ready, financeable, deployable, or execution-ready. Marketplace listings, Registry records, Reports references, Academy materials, Studio workflows, Grid inputs, TRL notes, and handoff packages shall be updated to reflect deprecation where applicable.

### 4.3.15 Archive.

Archive shall preserve software objects, repository states, release packages, documentation, dependency records, license records, security records, correction records, deprecation records, withdrawal records, recall records, Reports references, Registry status, Marketplace delisting history, Studio workflow history, Grid inputs, TRL notes, and handoff history for institutional memory, accountability, learning, and traceability. Archive records shall state access class, archive-not-current notice, historical use note, successor links, license status, support status, public-safe status, retention rule, and conditions for restricted access.

Archived software shall not be treated as current authority, supported product, certified tool, recommended implementation, procurement object, public authority tool, financeable asset, deployable system, or execution object. Archive access shall be governed by rights, security, privacy, protected knowledge, public-safe, and national sovereignty controls.

## 4.4 Software Quality Controls

### 4.4.1 Code review.

Code review shall examine correctness, maintainability, clarity, security, privacy, performance, interoperability, accessibility, public-safe implications, data-handling implications, AI-use implications, dependency implications, error handling, documentation adequacy, and alignment with object purpose. Code review shall be performed by qualified reviewers or maintainers appropriate to the object class, risk class, and release class.

Code review approval shall be a bounded evidence input. It shall not constitute certification, legal compliance, security certification, production approval, procurement recommendation, public authority approval, financeability, insurability, deployment authorization, or warranty. Code review records shall be preserved and correctionable.

### 4.4.2 Test coverage.

Test coverage shall provide evidence that software behavior has been evaluated within stated scope. Tests may include unit tests, integration tests, regression tests, security tests, accessibility tests, performance tests, data quality tests, model evaluation tests, API tests, dashboard tests, Studio workflow tests, and reproducibility tests. Test records shall identify test scope, coverage limitations, known gaps, environment assumptions, dependency requirements, and unresolved issues.

Test coverage shall not imply absence of defects or fitness for production. Passing tests shall not create certification, public authority approval, procurement readiness, financeability, insurability, deployment authorization, or execution authority.

### 4.4.3 Dependency scanning.

Dependency scanning shall identify vulnerabilities, outdated packages, license issues, abandoned packages, supply-chain risks, transitive dependency risks, malicious package risks, compatibility issues, and operational risk from external software components. Dependency scanning shall be performed before release where appropriate and repeated according to risk, support class, and lifecycle state.

Scanning results shall be recorded and used for correction, patching, replacement, suspension, withdrawal, or deprecation decisions. Dependency scanning shall not certify security, validate providers, guarantee compatibility, or approve downstream deployment.

### 4.4.4 Secret scanning.

Secret scanning shall identify exposed credentials, tokens, keys, passwords, certificates, connection strings, private URLs, sensitive configuration, infrastructure secrets, API credentials, and other protected information. Secret scanning shall apply to repositories, release packages, documentation, notebooks, templates, infrastructure-as-code, and logs where applicable.

Detected secrets shall trigger containment, rotation where applicable, removal, incident assessment, correction, Registry update where needed, and public-safe notice where appropriate. Secret scanning shall not replace secure development practices, access controls, least privilege, or incident response obligations.

### 4.4.5 SBOM records.

Software Bill of Materials records shall be used where appropriate to identify software components, dependencies, versions, licenses, suppliers or sources, package managers, transitive dependencies, known vulnerabilities, and update pathways. SBOM records shall support supply-chain transparency, security review, dependency management, handoff context, and correction propagation.

SBOM existence shall not certify security, guarantee absence of vulnerabilities, validate providers, create procurement approval, or create warranty. SBOM records shall be updated when software components, dependencies, release versions, or vulnerability status changes.

### 4.4.6 Vulnerability disclosure.

Vulnerability disclosure controls shall define how vulnerabilities are reported, triaged, contained, corrected, communicated, and archived. Software objects with public or controlled release shall identify a disclosure channel appropriate to support class and risk class. Vulnerability reports shall be handled with confidentiality, public-safe communication, no-exploit amplification, and correction discipline.

Disclosure of a vulnerability shall not be treated as public warning, operational command, or admission of liability by default. Vulnerability correction shall be recorded and propagated to Registry, Marketplace, Reports, Studio, Grid, TRL, handoff recipients, and archive records where applicable.

### 4.4.7 Threat modeling.

Threat modeling shall be applied where software risk warrants structured analysis of misuse, abuse, attack surfaces, access controls, data flows, AI-use risks, prompt-injection risks, model misuse, cyber-physical implications, critical infrastructure sensitivity, public authority sensitivity, geospatial sensitivity, protected knowledge exposure, sponsor or provider capture, and handoff risks. Threat models shall identify assumptions, threats, mitigations, residual risks, review needs, and correction triggers.

Threat modeling shall support better design and safer release, but shall not certify security, eliminate risk, approve deployment, or replace downstream operational security review. Threat models shall be updated when software architecture, data flows, runtime context, dependencies, access classes, or use cases materially change.

### 4.4.8 Secure defaults.

DDPGF software shall prefer secure defaults where feasible, including least privilege, disabled dangerous features by default, safe configuration, minimal data collection, logging appropriate to sensitivity, no hardcoded secrets, privacy-preserving settings, public-safe output restrictions, explicit permissions, dependency pinning where appropriate, input validation, output encoding, and controlled access modes for sensitive workflows.

Secure defaults shall not remove the need for user configuration, deployment review, operational security, monitoring, incident response, or legal compliance. Secure defaults shall reduce risk; they shall not create security certification, warranty, deployment authorization, or execution authority.

### 4.4.9 Accessibility testing.

Accessibility testing shall assess whether user-facing software, dashboards, documentation, reports packages, learning interfaces, Marketplace listings, Registry displays, Studio workflows, and public-safe outputs can be used by people with disabilities and by users in varied bandwidth, device, language, and localization contexts. Accessibility review may include screen-reader compatibility, keyboard navigation, color contrast, alt text, captions, structured headings, plain-language summaries, mobile access, low-bandwidth options, and multilingual metadata.

Accessibility status shall be recorded and corrected where feasible. Accessibility testing shall not create universal accessibility certification by default, but shall form part of public-good quality and inclusion discipline.

### 4.4.10 Documentation review.

Documentation review shall assess clarity, completeness, public-safe wording, boundary notices, installation instructions, usage instructions, configuration notes, security notes, privacy notes, data-use notes, AI-use notes, accessibility notes, support status, known limitations, license terms, contribution rules, correction pathway, archive rule, and handoff relevance. Documentation shall be reviewed when software changes materially, when release class changes, when vulnerabilities arise, when dependencies change, when public-safe status changes, or when correction is required.

Documentation review shall not create approval, warranty, legal compliance, certification, procurement readiness, or deployment authorization. Documentation shall remain correctionable and status-linked.

### 4.4.11 Reproducibility review.

Reproducibility review shall examine whether software results, builds, analyses, notebooks, data transformations, model evaluations, dashboards, simulations, or reports can be reproduced within recorded assumptions and environment constraints. Review may include environment files, container specifications, dependency locks, seed settings, dataset references, configuration files, test data, scripts, notebooks, execution notes, and output comparison.

Reproducibility within scope shall not imply universal validity, scientific finality, operational approval, certification, financeability, insurability, public authority approval, or deployment authorization. Reproducibility limits shall be documented.

### 4.4.12 Release notes.

Release notes shall document what changed, why it changed, affected object versions, new features, bug fixes, security updates, dependency changes, known issues, breaking changes, migration needs, public-safe implications, support status, correction history, and archive or deprecation references. Release notes shall accompany material releases and shall be linked to Registry records and Marketplace listings where applicable.

Release notes shall not create warranty or approval. They shall provide traceability, not authority. Release notes shall be corrected where they contain errors, omissions, overclaims, or outdated boundary statements.

## 4.5 Software Governance

### 4.5.1 Repository stewardship.

Repository stewardship shall assign responsibility for repository integrity, access controls, maintainer records, contribution rules, documentation quality, security channels, dependency review, issue triage, release preparation, correction, deprecation, withdrawal, and archive. Stewardship may be held by a designated institutional unit, maintainer group, Competence Cell, Working Group, Foundry program, National Node, or other authorized role within DDPGF governance.

Repository stewardship shall not imply ownership of all contributions, warranty, certification authority, procurement authority, provider validation, sponsor control, public authority approval, or execution authority. Repository stewards shall preserve public-good continuity, anti-capture discipline, correctionability, and role separation.

### 4.5.2 Maintainer standing.

Maintainer standing shall be recorded for persons or groups authorized to review, merge, release, document, triage, correct, deprecate, withdraw, or archive software within defined scope. Maintainer standing may be provisional, active, senior, domain-specific, data-specific, AI-specific, public-safe, safeguard, security, national portfolio, handoff-context, suspended, downgraded, removed, or archived depending on governance rules.

Maintainer standing shall not constitute professional license, certification authority, employment status, procurement status, provider validation, public authority approval, deployment authority, or execution authority. Maintainer actions shall be auditable, correctionable, conflict-managed, and role-bounded.

### 4.5.3 Contributor roles.

Contributor roles may include author, developer, data contributor, model contributor, reviewer, tester, translator, accessibility contributor, public-safe reviewer, safeguard reviewer, documentation contributor, maintainer, security reporter, community contributor, mentor, sponsor supporter, provider contributor, national node contributor, and handoff-context contributor. Each role shall be recorded where material to object status, attribution, review, support, correction, or archive.

Contributor status shall not create employment, compensation, ownership, authority, endorsement, certification, procurement status, public authority status, provider validation, sponsor control, deployment authorization, or execution authority by implication. Contributor recognition may be recorded through iCRS, ILA, WILPs, Academy, SCF, or Registry pathways where applicable.

### 4.5.4 Code of conduct.

A code of conduct shall govern behavior in DDPGF software repositories and related contribution environments. It shall support respectful collaboration, anti-harassment, inclusion, accessibility, public-interest conduct, community-sensitive conduct, Indigenous protocol-sensitive conduct where applicable, protected knowledge discipline, security-sensitive disclosure, no-exploitation, no-retaliation, conflict disclosure, and correction cooperation.

Violation of the code of conduct may trigger warning, moderation, contribution restriction, maintainer review, suspension, removal, correction, or archive actions. Code-of-conduct enforcement shall not replace legal remedies, employment law, public authority processes, criminal law, professional discipline, or contractual remedies where applicable.

### 4.5.5 Contribution license agreements where required.

Contribution license agreements or comparable contribution terms may be required where necessary to clarify rights, licenses, attribution, patent-sensitive issues, re-use permissions, contributor representations, public-good continuity, documentation rights, and downstream distribution conditions. Such agreements shall be proportionate, transparent, and aligned with public-good, anti-capture, and anti-enclosure discipline.

Contribution terms shall not be used to extract protected knowledge, override community rights, bypass Indigenous protocols, impose hidden exclusivity, transfer employment status, create sponsor ownership by implication, validate providers, or collapse public-good stack and enterprise-stack boundaries. Contribution terms shall be reviewed where rights, licensing, data, model, or protected knowledge issues arise.

### 4.5.6 Security disclosure channels.

Security disclosure channels shall be maintained for software objects where vulnerabilities, weaknesses, misconfigurations, exposed secrets, dependency risks, model risks, prompt-injection risks, API risks, or infrastructure risks may arise. Channels shall specify reporting method, confidentiality expectations, triage process, response posture according to support class, public-safe communication rules, correction pathway, and archive process.

Security disclosure channels shall not guarantee response times unless separately agreed, nor shall they create security certification, liability assumption, public warning authority, or operational command. They shall create a governed route for risk reporting and correction.

### 4.5.7 Support status.

Support status shall be recorded for each software object according to support classification. Support status shall identify whether support is unavailable, community-based, maintainer-based, Academy-based, Foundry-based, National Node-based, Studio-based, handoff-recipient-based, time-limited, security-only, deprecated, or archived. Support status shall be visible in Registry and Marketplace records where applicable.

Support status shall not create warranty, service-level agreement, continuous maintenance obligation, professional assurance, cybersecurity guarantee, procurement readiness, financeability, deployment authorization, or execution authority by default. Support changes shall be recorded and communicated through correction, deprecation, or archive notices where necessary.

### 4.5.8 Roadmap governance.

Roadmap governance shall structure planned software development, maintenance, improvements, localization, accessibility upgrades, security improvements, interoperability work, documentation improvements, Studio readiness, Marketplace readiness, Registry updates, Reports integration, Grid inputs, TRL evidence notes, Nexus Universe preparation, and handoff-context enhancements. Roadmaps may be global, regional, national, thematic, sectoral, Foundry-specific, Academy-specific, Studio-specific, or handoff-specific.

Roadmaps shall remain plans and priorities, not promises, procurement commitments, sponsor entitlements, provider preferences, finance commitments, public authority obligations, deployment schedules, or execution commitments. Roadmap items may be changed, deferred, corrected, withdrawn, archived, or made non-continuing according to DDPGF governance.

### 4.5.9 Fork governance.

Fork governance shall address copies, adaptations, national localizations, provider-specific adaptations, research adaptations, Studio-only variants, secure-room variants, handoff-recipient variants, and experimental branches of DDPGF software. Fork records shall identify source object, fork purpose, steward, version, license, changes, localization, access class, support class, public-safe status, dependency differences, review differences, correction responsibilities, and archive rule.

Forking shall not create endorsement, approval, certification, provider validation, procurement status, public authority adoption, financeability, deployment authorization, or execution authority. Forks shall not misuse Nexus names, Registry status, Marketplace language, public-safe claims, or original support status. Corrections affecting source objects shall be assessed for propagation to forks where applicable.

### 4.5.10 Correction and withdrawal.

Software governance shall include clear authority and process for correction and withdrawal. Correction may address errors, defects, vulnerabilities, documentation overclaims, license issues, dependency risks, security incidents, privacy incidents, AI incidents, public-safe incidents, protected knowledge incidents, sponsor or provider boundary incidents, public authority boundary incidents, finance or procurement overclaims, handoff overclaims, or execution overclaims. Withdrawal may occur where continued availability would create unacceptable risk, rights violation, public-safe risk, security risk, legal risk, boundary risk, or trust risk.

Correction and withdrawal shall be recorded in the Registry, reflected in Marketplace listings, communicated through public-safe notices where appropriate, propagated to Reports, Studio, Grid, TRL, National Portfolios, Nexus Universe records, and handoff recipients where applicable, and preserved in archive. Withdrawal shall not erase institutional memory unless deletion or sealing is legally or ethically required.

## 4.6 Software Boundary Rules

### 4.6.1 Software release is not warranty.

No DDPGF software release, whether draft, controlled, open public, Marketplace-listed, Registry-recorded, Studio-ready, Grid-routed, TRL-noted, Reports-linked, Nexus Universe-demonstrated, National Portfolio-linked, or handoff-context-included, shall create an implied warranty, fitness-for-purpose assurance, uptime guarantee, security guarantee, legal compliance guarantee, professional assurance, or service-level obligation unless separately and lawfully recorded in a written agreement.

### 4.6.2 Reference implementation is not production approval.

No reference implementation shall be treated as production approval, operational approval, public authority approval, safety approval, cybersecurity certification, procurement recommendation, provider validation, financeability, insurability, deployment authorization, or execution authority. A reference implementation shall demonstrate one bounded method of implementation and shall remain subject to independent review before any downstream operational use.

### 4.6.3 Open-source availability is not deployment authorization.

Open-source availability, public repository access, downloadable code, permissive licensing, published documentation, community contribution, public demonstration, Marketplace discovery, or Reports publication shall not authorize deployment. Deployment requires separate lawful authority, technical review, operational validation, security hardening, privacy review, data rights review, public authority approvals where applicable, procurement compliance where applicable, community and Indigenous protocols where applicable, and competent execution by lawful actors.

### 4.6.4 Code review is not security certification.

Code review, dependency scanning, secret scanning, test coverage, threat modeling, SBOM creation, vulnerability disclosure readiness, secure-default design, or security review shall not constitute security certification unless a competent certification authority separately and lawfully certifies within a defined scope. DDPGF security controls produce evidence and correction pathways; they do not eliminate risk or create certification by implication.

### 4.6.5 Marketplace listing is not procurement recommendation.

Marketplace listing of software shall not constitute procurement recommendation, approved supplier status, vendor validation, provider preference, tender support, public authority endorsement, finance signal, insurance signal, implementation authorization, or execution authority. Any procurement, vendor selection, contracting, finance, insurance, or implementation decision shall occur outside DDPGF default posture through competent lawful processes.

### 4.6.6 Provider contribution is not provider validation.

Provider contribution to DDPGF software, including code, documentation, infrastructure, data connectors, APIs, services, cloud credits, engineering support, testing support, security support, sponsorship, hosting, or demonstration support, shall not validate the provider, certify its products, create procurement preference, create exclusivity, create sponsor control, create public authority approval, create financeability, create insurance approval, or imply that the provider is endorsed by Nexus, The Global Centre for Risk and Innovation, The Global Risks Forum, The Global Risks Alliance, any Nexus Consortium, any National Node, any public authority, or any DDPGF steward. Provider contributions shall be recorded, bounded, reviewable, correctionable, and subject to anti-capture and no-conversion controls.


---

# 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/iv.-software.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.