# IX. SOFTWARE

Nexus Agile Framework Software defines the **NAF public-good software model** for reusable, evidence-bearing, and securely governed software objects. This section explains how **repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, notebooks, infrastructure templates, and reference implementations** are built, reviewed, released, and supported.

This section sets the operating model for **software object classes**, **repository and release governance**, **secure software controls**, **support classes**, **software metrics**, and **software boundaries**. It helps Nexus publish open-source and controlled software with strong records, secure release discipline, public-safe limits, and lawful handoff clarity without creating warranty, procurement recommendation, deployment approval, or execution by implication.

### What this section covers

* **Software governance** - Defines public-good software doctrine, object classes, and repository controls.
* **Secure release discipline** - Explains code review, test coverage, dependency scanning, SBOM records, and release notes.
* **Boundary controls** - Defines support classes, Marketplace and Registry truth, and no-warranty, no-procurement, no-deployment rules.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [VII. FOUNDRY](/organization/operations/frameworks/nexus-agile-framework-naf/vii.-foundry.md) for software build pathways, [VIII. R\&D](/organization/operations/frameworks/nexus-agile-framework-naf/viii.-r-and-d.md) for methods and research translation, and [IV. LIFECYCLE](/organization/operations/frameworks/nexus-agile-framework-naf/iv.-lifecycle.md) for review, release, correction, and archive discipline.

## 9.1 Public-Good Software Doctrine

### 9.1.1 Software as Public-Good Object.

9.1.1.1 Software within NAF shall be treated as a public-good object when it is created, maintained, adapted, documented, tested, released, listed, recorded, taught, demonstrated, localized, or prepared for handoff in support of Nexus public-good purposes, including all-hazards resilience, WFEH-B systems, DRR, DRF, DRI, public authority learning, public-safe reporting, observability, risk intelligence, evidence methods, open technical baselines, standards-interface records, National Portfolio formation, Nexus Universe preparation, and lawful downstream capability formation.

9.1.1.2 A public-good software object may include code, repository structure, documentation, tests, APIs, SDKs, connectors, adapters, dashboards, notebooks, infrastructure-as-code, reference implementations, model evaluation tools, data tools, Studio workflow components, Registry tools, Marketplace tools, Reports tools, Campaign tools, Academy tools, DICE tools, GRIx tools, DRI tools, Observatory tools, Rails tools, Network tools, National Node tools, and handoff dependency tooling.

9.1.1.3 Public-good software status shall require records. A software object shall carry identity, purpose, scope, steward, maintainer, contributors, license status, attribution, version, release class, support class, repository status, documentation status, test status, security status, dependency status, SBOM status where applicable, accessibility status, public-safe status, data-use status where applicable, AI-use status where applicable, safeguard status where applicable, Registry status, Marketplace eligibility, correction pathway, withdrawal pathway, deprecation pathway, and archive rule.

9.1.1.4 Public-good software shall not be reduced to “open code.” Software may be open, controlled, internal, secure-room-only, data-room-only, Studio-only, handoff-recipient-only, unsupported, community-supported, maintainer-supported, National Node-supported, or archived according to release class, support class, sensitivity, data rights, AI-use constraints, cyber risk, safeguard obligations, public-safe requirements, and lawful handoff conditions.

### 9.1.2 Software as Evidence-Bearing Capability.

9.1.2.1 Software under NAF shall be treated as evidence-bearing capability when it demonstrates a method, implements an open technical baseline, supports reproducibility, enables a Studio workflow, structures data, produces a dashboard, implements a DRI indicator, supports GRIx mappings, executes a controlled workflow, documents a model, supports public-safe reporting, supports National Portfolio formation, or prepares bounded handoff context.

9.1.2.2 Evidence-bearing software shall record what it proves, what it does not prove, what data it uses, what assumptions it encodes, what dependencies it has, what environment it was tested in, what limitations apply, what risks remain, what review was completed, what support exists, and what correction pathway applies.

9.1.2.3 Software evidence shall remain bounded. A working prototype, repository, dashboard, API, notebook, test suite, model interface, simulation tool, digital twin component, or reference implementation may support evidence and learning, but shall not by itself create approval, certification, security assurance, procurement status, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 9.1.3 Software as Workflow, Not Authority.

9.1.3.1 Software within NAF may structure workflow, guide review, automate low-risk tasks, assist evidence assembly, support data processing, provide dashboards, enable Studio workflows, support Registry and Marketplace functions, facilitate Academy learning, support Campaign operations, manage Dockets, route records, or generate public-safe summaries under review. Software shall not become authority by design, implication, automation, interface, dashboard presentation, ranking, recommendation, workflow state, or user reliance.

9.1.3.2 No software object shall be designed or represented as making public authority decisions, finance decisions, insurance decisions, procurement decisions, community consent determinations, Indigenous consent determinations where applicable, certification determinations, safety determinations, legal compliance determinations, emergency commands, operational commands, deployment decisions, or execution instructions within NAF’s default posture.

9.1.3.3 Where software supports decision-relevant learning, it shall carry human review requirements, no-automated-authority notices, public authority boundary notices, finance and procurement boundary notices, public-safe notices, data-use labels, AI-use labels, output classification, logs where appropriate, correction pathways, and archive rules.

### 9.1.4 Software as Reusable Public-Good Asset.

9.1.4.1 Software shall be designed for reuse where safe and appropriate. Reuse may include reuse across countries, regions, sectors, hazard domains, technology domains, National Portfolios, Nexus Universe cycles, Academy cohorts, Foundry builds, Studio workflows, DICE environments, DRI dashboards, GRIx mappings, Reports, Registry records, Marketplace listings, and lawful handoff dependency packages.

9.1.4.2 Reuse shall require clear metadata, documentation, versioning, licensing, support status, dependency records, security notices, configuration notes, environment notes, localization notes, public-safe restrictions, data and AI labels, accessibility status, known limitations, correction history, deprecation status, and archive status.

9.1.4.3 Reuse shall not imply fitness for every context. A reusable software object remains bounded by its scope, release class, support class, license, data assumptions, infrastructure assumptions, jurisdictional context, public-safe limits, safeguard conditions, and handoff dependency notes.

### 9.1.5 Software as Bounded Support Class.

9.1.5.1 Every NAF software object shall carry a support class. Support classes may include unsupported public release, community-supported, maintainer-supported, Academy-supported, Foundry-supported, Studio-supported, National Node-supported, handoff-recipient-supported, time-limited support, security-maintained, deprecated support, archived support, or non-continuing.

9.1.5.2 Support class shall state who may respond to issues, whether updates are expected, whether security notices are monitored, whether dependencies are reviewed, whether documentation is current, whether accessibility is maintained, whether localization is supported, whether public-safe review is current, whether integration support exists, and whether the object is eligible for Registry, Marketplace, Studio, Grid, TRL, National Portfolio, Nexus Universe, or handoff routing.

9.1.5.3 Support class shall not create warranty, service-level guarantee, procurement eligibility, financeability, insurance approval, public authority approval, certification, deployment authorization, or execution obligation.

### 9.1.6 Software Without Warranty by Default.

9.1.6.1 NAF software shall be provided without warranty by default unless a separate lawful written agreement expressly states otherwise. Public-good release, open-source publication, repository availability, Marketplace listing, Registry status, Nexus Universe demonstration, Academy use, Studio use, Grid input, TRL note, or handoff dependency package shall not create warranty, fitness-for-purpose representation, service-level commitment, uptime obligation, security guarantee, or operational guarantee.

9.1.6.2 No warranty by default shall not excuse negligence in records, correction, security discipline, public-safe communication, or boundary notices. Software stewards and maintainers shall still maintain accurate records, known issue notices, correction pathways, release classes, support classes, and archive rules.

9.1.6.3 Any separate warranty, service-level, implementation, hosting, operational, procurement, managed service, or enterprise support arrangement must be created outside NAF’s default public-good posture by a competent lawful actor and shall not be implied from NAF software release.

### 9.1.7 Software Without Procurement Implication.

9.1.7.1 Software release, demonstration, listing, Registry record, support status, public-safe summary, Foundry build, Studio workflow, Grid input, TRL note, Nexus Universe use, National Portfolio reference, or handoff dependency package shall not be treated as procurement recommendation, supplier approval, vendor validation, preferred provider status, tender qualification, procurement specification, sole-source basis, or purchasing instruction.

9.1.7.2 Provider contribution to software shall be recorded as contribution only. Provider contribution shall not validate the provider, create procurement preference, imply compatibility across all contexts, or convert software into a procurement-ready solution.

9.1.7.3 Any procurement decision must occur through separate competent procurement processes, independent diligence, lawful authority, competition and conflict controls, and applicable public or private procurement rules outside NAF’s default software posture.

### 9.1.8 Software Without Deployment Authorization.

9.1.8.1 Software developed, tested, demonstrated, released, listed, recorded, taught, or routed under NAF shall not be treated as deployment authorization. A software object may be ready for learning, demonstration, review, integration testing, Studio use, public-good reuse, Registry record, Marketplace discovery, Grid input, TRL evidence note, Nexus Universe presentation, or handoff context without being authorized for operational deployment.

9.1.8.2 Deployment, where appropriate, shall require separate lawful authority, implementation responsibility, operational controls, security review, privacy review, data rights, public authority approvals where required, procurement approvals where required, finance and insurance decisions where relevant, community processes where required, Indigenous processes where applicable, and recipient accountability.

9.1.8.3 NAF software shall preserve the difference between building capability and executing implementation. Software may support lawful actors; it shall not become lawful authority.

## 9.2 Software Object Classes

### 9.2.1 Repositories.

9.2.1.1 Repositories are governed containers for software source code, documentation, configuration files, tests, issues, release notes, security notices, contribution records, licenses, metadata, governance files, and archive records. Repositories shall be assigned identity, steward, maintainer, license, access class, support class, release class, contribution model, review rules, security disclosure channel, correction pathway, and archive rule.

9.2.1.2 Repository types may include public repositories, controlled repositories, internal repositories, secure repositories, national repositories, National Node repositories, Nexus Universe repositories, Foundry repositories, Academy repositories, Studio repositories, DICE repositories, DRI repositories, GRIx repositories, Observatory repositories, Rails repositories, Reports repositories, Marketplace repositories, Registry repositories, and handoff-recipient repositories.

9.2.1.3 Repository existence shall not imply software maturity, approval, support, warranty, certification, procurement status, financeability, public authority approval, deployment authorization, or execution.

### 9.2.2 Libraries.

9.2.2.1 Libraries are reusable software components that provide functions, methods, utilities, data transformations, model helpers, API clients, schema tools, ontology tools, DRI indicator logic, GRIx mapping logic, public-safe transformation helpers, dashboard components, Studio components, or other reusable capabilities.

9.2.2.2 Libraries shall include versioning, documentation, usage examples, license, dependencies, test status, security status, support class, public-safe limitations where applicable, data and AI constraints where applicable, and correction pathway.

9.2.2.3 Library use shall remain the responsibility of the user or lawful recipient. Library availability shall not create warranty, certification, production approval, procurement recommendation, or deployment authorization.

### 9.2.3 Services.

9.2.3.1 Services are software components that run as hosted or executable functions, APIs, background processors, workflow engines, data processors, dashboards, notification systems, registry services, marketplace services, Studio services, DICE services, Observatory services, DRI services, Rails services, or controlled-room services.

9.2.3.2 Services shall include service identity, environment, access controls, logging, dependency records, uptime status where applicable, support class, security controls, privacy controls, data-use labels, AI-use labels where applicable, incident pathway, correction pathway, and teardown rule.

9.2.3.3 Service availability shall not create service warranty, service-level guarantee, public authority approval, operational command, deployment authorization, procurement status, financeability, or execution.

### 9.2.4 Applications.

9.2.4.1 Applications are user-facing or operator-facing software systems created under NAF for learning, contribution, reporting, dashboarding, workflow, registry, marketplace, campaign, studio, data, risk intelligence, observability, or handoff support purposes.

9.2.4.2 Applications shall include user roles, access classes, data flows, AI-use labels where applicable, public-safe output controls, accessibility controls, localization controls, security controls, privacy controls, support class, release class, issue reporting, correction pathway, withdrawal pathway, and archive rule.

9.2.4.3 Application use shall not create official action, automated decision authority, finance decision, procurement decision, certification, consent, deployment authorization, or execution.

### 9.2.5 Dashboards.

9.2.5.1 Dashboards are visual software objects that present Docket status, National Portfolio status, Foundry status, Campaign status, Academy status, Reports status, Marketplace status, Registry status, DICE status, GRIx status, DRI status, Observatory status, Studio status, Grid status, TRL status, Nexus Universe status, correction status, archive status, or handoff dependency status.

9.2.5.2 Dashboards shall include data source notes, update cadence, confidence labels where applicable, uncertainty labels where applicable, limitations, sensitive data controls, public-safe notices, accessibility review, localization notes, correction pathway, and archive rule.

9.2.5.3 Dashboards shall not be treated as decisions, ratings, rankings by default, public warnings, public authority actions, insurance scores, investment signals, procurement scores, operational commands, deployment authorizations, or execution instructions.

### 9.2.6 APIs and SDKs.

9.2.6.1 APIs and SDKs are interface objects that allow controlled interaction with Nexus software, data, registry, marketplace, studio, reports, campaign, academy, DRI, GRIx, DICE, Observatory, Rails, Network, or National Node functions.

9.2.6.2 APIs and SDKs shall include authentication, authorization, rate limits where applicable, access class, data minimization, public-safe output filtering, abuse prevention, logging, versioning, deprecation notices, documentation, license status, support class, security notices, correction pathway, and archive rule.

9.2.6.3 API or SDK availability shall not create data rights, unrestricted access, interoperability certification, provider validation, procurement status, financeability, public authority approval, deployment authorization, or execution.

### 9.2.7 Connectors and Adapters.

9.2.7.1 Connectors and Adapters are software objects that link Nexus systems to external systems, data sources, repositories, APIs, platforms, public authority systems, standards-interface systems, provider systems, national systems, Observatory nodes, Studio workflows, or handoff-recipient systems.

9.2.7.2 Connectors and Adapters shall include source and destination descriptions, data flow records, permission model, access controls, transformation rules, error handling, public-safe filters, security review, dependency review, provider-neutrality notes, support class, correction pathway, and archive rule.

9.2.7.3 Connector availability shall not validate a provider, approve a system, certify interoperability, create data rights, authorize integration, create procurement status, or authorize deployment.

### 9.2.8 Command-Line Tools.

9.2.8.1 Command-Line Tools are software utilities used for data processing, repository maintenance, testing, validation, documentation generation, metadata generation, public-safe transformation, package creation, release management, or archive management.

9.2.8.2 Command-Line Tools shall include usage documentation, required permissions, input and output descriptions, safety warnings, data-use constraints, AI-use constraints where applicable, logging behavior, test status, dependency records, support class, correction pathway, and archive rule.

9.2.8.3 Command-Line Tool availability shall not create operational command authority, deployment authorization, warranty, certification, or execution authority.

### 9.2.9 Notebooks and Reproducibility Packages.

9.2.9.1 Notebooks and Reproducibility Packages shall support transparent analysis, methods demonstration, data transformation, model evaluation, visualization, benchmark reproduction, DRI indicator explanation, Observatory analysis, Studio scenario preparation, Reports evidence, Academy learning, and Grid or TRL evidence.

9.2.9.2 Such packages shall include environment files, dependencies, data availability statements, data-use labels, AI-use labels, execution instructions, expected outputs, limitations, public-safe restrictions, security warnings, license, support class, correction pathway, and archive rule.

9.2.9.3 Reproducibility shall not imply correctness across all contexts, approval, certification, deployment authorization, public authority decision, financeability, procurement readiness, or execution.

### 9.2.10 Infrastructure-as-Code Templates.

9.2.10.1 Infrastructure-as-Code Templates are software objects that describe deployable or reproducible infrastructure configurations for cloud, edge, secure rooms, data rooms, compute-to-data environments, Studio environments, observability systems, dashboards, repositories, APIs, or National Node infrastructure.

9.2.10.2 Infrastructure-as-Code Templates shall include environment assumptions, security defaults, identity and access controls, data residency notes, cost and support notes, provider-neutrality notes, secrets handling rules, logging, monitoring, teardown rules, support class, correction pathway, and archive rule.

9.2.10.3 Infrastructure-as-Code availability shall not authorize deployment, validate a provider, create service warranty, create public authority approval, create procurement status, create data rights, or execute infrastructure by implication.

### 9.2.11 Test Suites.

9.2.11.1 Test Suites are software objects that support code quality, data validation, model evaluation, API behavior, dashboard behavior, accessibility, security checks, interoperability checks, regression checks, reproducibility, release readiness, and correction validation.

9.2.11.2 Test Suites shall include test scope, expected behavior, assumptions, environment, pass/fail criteria, limitations, coverage status, dependency status, support class, correction pathway, and archive rule.

9.2.11.3 Passing a Test Suite shall not create security certification, production approval, interoperability certification, procurement readiness, financeability, public authority approval, deployment authorization, or execution.

### 9.2.12 Reference Implementations.

9.2.12.1 Reference Implementations are example software implementations of methods, protocols, schemas, APIs, workflows, dashboards, data pipelines, AI-use patterns, Studio workflows, DRI indicators, GRIx mappings, Registry records, Marketplace listings, Grid inputs, TRL notes, or handoff package structures.

9.2.12.2 Reference Implementations shall include scope, intended learning use, prohibited use, assumptions, dependencies, license, support class, testing status, security status, limitations, public-safe status, correction pathway, and archive rule.

9.2.12.3 A Reference Implementation is not a production system, certification, standard, procurement specification, provider validation, financeability signal, public authority approval, deployment authorization, or execution.

## 9.3 Repository and Release Governance

### 9.3.1 Repository Stewardship.

9.3.1.1 Each repository shall have a steward or stewardship body responsible for repository purpose, governance, access class, license, maintainer assignment, contributor rules, documentation, release class, support class, security disclosure, issue handling, correction, withdrawal, deprecation, and archive.

9.3.1.2 Repository stewardship shall preserve role separation and public-good firewall discipline. Stewardship may be performed by or under a Nexus body, National Node, Foundry program, Competence Cell, Guild, maintainer group, or other recorded structure, but stewardship shall not create ownership, certification authority, public authority status, procurement authority, finance authority, deployment authority, or execution authority.

9.3.1.3 Repository stewardship shall ensure that repository claims remain accurate, bounded, public-safe, and correctionable.

### 9.3.2 Maintainer Standing.

9.3.2.1 Software Maintainer Standing shall identify who may review, merge, release, deprecate, withdraw, archive, or correct software objects within defined scope. Standing may be provisional, active, limited, suspended, downgraded, withdrawn, retired, archived, or reinstated.

9.3.2.2 Maintainer Standing shall be based on competence, contribution record, review quality, security discipline, public-safe discipline, documentation discipline, conflict status, correction responsiveness, support capacity, and compliance with Nexus boundaries.

9.3.2.3 Maintainer Standing shall not create professional certification, employment status, public authority status, procurement authority, provider validation, financeability, deployment authority, or execution authority.

### 9.3.3 Contributor Roles.

9.3.3.1 Contributor Roles may include author, developer, reviewer, tester, data contributor, model contributor, documentation contributor, translator, accessibility contributor, security reporter, public-safe reviewer, safeguard reviewer, maintainer, mentor, sponsor supporter, provider contributor, community contributor, and National Node contributor.

9.3.3.2 Contributor Roles shall be recorded with scope, contribution type, attribution, license status, conflict status where applicable, support status, review status, correction pathway, and archive linkage.

9.3.3.3 Contributor status shall not create employment, agency, certification authority, procurement status, provider validation, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 9.3.4 Code of Conduct.

9.3.4.1 Software repositories shall maintain conduct rules appropriate to public-good collaboration, including respect, non-harassment, non-discrimination, accessibility, inclusion, public-safe communication, confidentiality where required, protected knowledge controls, cybersecurity responsibility, conflict disclosure, sponsor/provider boundary discipline, and correction obligations.

9.3.4.2 Code of Conduct enforcement may include warning, moderation, access limitation, contribution rejection, maintainer limitation, suspension, removal, correction, or archive of affected records.

9.3.4.3 Conduct enforcement shall not determine professional licensing, employment status, legal liability, public authority status, or certification unless separately and lawfully determined by competent actors.

### 9.3.5 Contribution Terms.

9.3.5.1 Contribution Terms shall define how software contributions are submitted, reviewed, licensed, attributed, accepted, rejected, modified, corrected, withdrawn, or archived. Contribution Terms may include contributor license agreements, developer certificates of origin, sign-off requirements, IP representations, license compatibility, confidentiality restrictions, protected knowledge restrictions, data restrictions, AI-use disclosures, and security disclosure rules.

9.3.5.2 Contributions shall not be accepted where rights are unclear, license compatibility is unresolved, sensitive data is improperly included, secrets are exposed, protected knowledge is improperly disclosed, malicious code is suspected, or sponsor/provider influence is undisclosed.

9.3.5.3 Contribution acceptance shall not create employment, warranty, certification, procurement status, provider validation, public authority approval, deployment authorization, or execution.

### 9.3.6 License and Attribution Review.

9.3.6.1 License and Attribution Review shall verify that software objects, dependencies, documentation, data, models, images, templates, and other included materials have compatible licenses, accurate attribution, permitted use, and recorded restrictions.

9.3.6.2 Review shall consider open-source licenses, documentation licenses, data licenses, model licenses, third-party dependency licenses, restricted-use conditions, non-commercial restrictions where applicable, no-AI-training restrictions where applicable, protected knowledge exclusions, trade secret exclusions, patent-sensitive issues, and handoff-recipient restrictions where applicable.

9.3.6.3 License review shall not create legal advice by default, warranty, procurement approval, commercial permission beyond the license, endorsement, deployment authorization, or execution.

### 9.3.7 Security Disclosure Channels.

9.3.7.1 Software repositories shall maintain appropriate security disclosure channels for vulnerabilities, secrets exposure, dependency risks, insecure defaults, cyber-sensitive issues, abuse risks, and security incidents. Such channels may include private reporting, embargo processes, public-safe disclosure procedures, maintainer escalation, cyber gate review, Registry status update, Marketplace delisting, release suspension, correction, withdrawal, recall, and archive.

9.3.7.2 Security Disclosure Channels shall protect reporters, users, maintainers, affected systems, and public safety while preserving correctionability and responsible disclosure.

9.3.7.3 Security disclosure shall not by itself create public warning authority, security certification, legal compliance determination, operational command, deployment authorization, or execution.

### 9.3.8 Support Status.

9.3.8.1 Support Status shall be recorded for each software object. It shall state whether the object is unsupported, community-supported, maintainer-supported, Foundry-supported, Academy-supported, Studio-supported, National Node-supported, handoff-recipient-supported, time-limited supported, deprecated, archived, or non-continuing.

9.3.8.2 Support Status shall include expected response channels, update expectations, security support, dependency support, documentation support, accessibility support, localization support, integration support, known issue handling, end-of-support notice, and archive rule.

9.3.8.3 Support Status shall not create warranty, service-level agreement, procurement eligibility, financeability, insurance approval, public authority approval, deployment authorization, or execution unless separately and lawfully contracted outside NAF.

### 9.3.9 Fork Governance.

9.3.9.1 Fork Governance shall define how software forks, derivative works, localized versions, national versions, experimental versions, secure-room versions, handoff-recipient versions, and archived versions are identified, attributed, licensed, reviewed, supported, corrected, and distinguished from official or maintained versions.

9.3.9.2 Forks shall not misrepresent status, support, endorsement, Registry standing, Marketplace status, Nexus affiliation, provider validation, sponsor support, public authority approval, certification, procurement status, or deployment authorization.

9.3.9.3 Fork Governance shall preserve public-good continuity while preventing confusion, enclosure, hidden exclusivity, sponsor capture, provider capture, and status overclaim.

### 9.3.10 Correction and Withdrawal.

9.3.10.1 Software Correction may include patch, hotfix, erratum, release note correction, documentation correction, security notice, dependency update, license correction, attribution correction, data removal, model removal, configuration correction, public-safe notice, Registry update, Marketplace update, Studio restriction, Grid correction, TRL correction, handoff recall, deprecation, withdrawal, recall, archive, or non-continuation.

9.3.10.2 Withdrawal shall occur where a software object should no longer be used, displayed, listed, released, routed, demonstrated, integrated, or handed off within its prior status. Withdrawal records shall include reason, affected versions, successor objects where any, user notice, Registry update, Marketplace action, support implications, correction pathway, and archive rule.

9.3.10.3 Correction and Withdrawal shall be treated as trust infrastructure. Corrected software is not failed software by default; uncorrectable software is not suitable for Nexus trust.

## 9.4 Secure Software Controls

### 9.4.1 Code Review.

9.4.1.1 Code Review shall be required for software movement into defined release classes, including controlled public, open public, Marketplace candidate, Registry-recorded, Studio-use, Grid input, TRL note, Nexus Universe-ready, and handoff-recipient-only contexts.

9.4.1.2 Code Review shall consider correctness, readability, maintainability, security, privacy, data handling, AI-use implications, public-safe outputs, accessibility, dependency use, license compatibility, test adequacy, documentation, support class, release class, and correction pathway.

9.4.1.3 Code Review acceptance shall not create security certification, production approval, provider validation, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 9.4.2 Test Coverage.

9.4.2.1 Test Coverage shall be recorded for software objects according to object class, risk, release class, support class, and intended use. Tests may include unit tests, integration tests, regression tests, security tests, accessibility tests, data validation tests, API contract tests, model evaluation tests, dashboard tests, Studio workflow tests, reproducibility tests, and public-safe output tests.

9.4.2.2 Test Coverage records shall identify what is tested, what is not tested, what assumptions apply, what environments were used, what limitations remain, and what correction pathway exists.

9.4.2.3 Test Coverage shall not create general validation, certification, warranty, procurement readiness, financeability, public authority approval, deployment authorization, or execution.

### 9.4.3 Dependency Scanning.

9.4.3.1 Dependency Scanning shall identify third-party packages, libraries, services, containers, models, datasets, APIs, and infrastructure dependencies used by software objects. Scanning shall consider known vulnerabilities, license compatibility, deprecated packages, unsupported dependencies, supply-chain risks, transitive dependencies, and update needs.

9.4.3.2 Dependency records shall include dependency identity, version, license, vulnerability status, update status, support status, known risks, mitigation, correction pathway, and archive relevance.

9.4.3.3 Dependency Scanning shall not create security certification, legal clearance by default, service warranty, procurement approval, or deployment authorization.

### 9.4.4 Secret Scanning.

9.4.4.1 Secret Scanning shall be used to detect credentials, keys, tokens, passwords, certificates, private endpoints, sensitive configuration values, and other secret material in repositories, release packages, notebooks, templates, logs, documentation, examples, and archives.

9.4.4.2 Secret exposure shall trigger immediate containment, revocation where appropriate, correction, Registry update where applicable, Marketplace action where applicable, public-safe notice where necessary, incident record, and archive update.

9.4.4.3 Secret Scanning shall not create complete assurance that no secrets exist. It is a control, not a guarantee.

### 9.4.5 SBOM Records.

9.4.5.1 Software Bill of Materials records shall be prepared where appropriate for software objects with dependencies, release packages, handoff relevance, Studio deployment relevance, public-good reuse, enterprise support relevance, or cyber-sensitive use. SBOM Records shall identify components, versions, licenses, suppliers where known, dependency relationships, known vulnerabilities, update status, and support status.

9.4.5.2 SBOM Records shall support transparency, security review, dependency correction, vulnerability response, handoff dependency context, and archive integrity.

9.4.5.3 SBOM Records shall not create security certification, supplier validation, procurement approval, legal compliance determination, warranty, deployment authorization, or execution.

### 9.4.6 Vulnerability Disclosure.

9.4.6.1 Vulnerability Disclosure shall be governed by responsible reporting, severity classification, impact analysis, maintainer escalation, remediation planning, embargo where appropriate, public-safe disclosure, Registry status update, Marketplace delisting or restriction where appropriate, release correction, withdrawal, recall, and archive.

9.4.6.2 Vulnerability Disclosure shall avoid harmful technical detail in public materials where disclosure may enable exploitation. Public-safe summaries shall be used where appropriate.

9.4.6.3 Vulnerability Disclosure shall not create public warning authority, security certification, operational command, public authority approval, deployment authorization, or execution.

### 9.4.7 Threat Modeling.

9.4.7.1 Threat Modeling shall be applied to software objects where risk warrants it, including data systems, AI systems, APIs, dashboards, Studio workflows, secure-room tools, Observatory tools, DRI tools, Registry tools, Marketplace tools, public-facing applications, infrastructure templates, and handoff-relevant software.

9.4.7.2 Threat Modeling shall consider actors, assets, attack surfaces, data flows, trust boundaries, misuse cases, abuse pathways, prompt injection where applicable, tool abuse where applicable, data leakage, identity risks, dependency risks, public-safe disclosure risks, and correction needs.

9.4.7.3 Threat Modeling shall not create security certification, compliance determination, warranty, deployment authorization, or execution.

### 9.4.8 Secure Defaults.

9.4.8.1 Software objects shall use secure defaults where appropriate, including least privilege, secure configuration, no embedded secrets, safe logging, safe error handling, access control, restricted data outputs, public-safe output filtering, privacy-preserving defaults, disabled dangerous functions by default, no-command defaults where applicable, no-write-back defaults where applicable, and human review defaults for AI-assisted workflows.

9.4.8.2 Secure defaults shall be documented, tested where appropriate, and preserved across releases, forks, localized versions, Studio uses, National Node deployments, and handoff-recipient packages.

9.4.8.3 Secure defaults reduce risk but do not create security certification, warranty, compliance determination, deployment authorization, or execution.

### 9.4.9 Accessibility Testing.

9.4.9.1 Accessibility Testing shall be applied to user-facing software, dashboards, documentation, learning tools, Campaign tools, Marketplace listings, Registry public interfaces, Reports interfaces, Studio interfaces, and public-safe outputs. Testing shall consider screen-reader compatibility, keyboard navigation, captions, alt text, contrast, plain-language summaries, multilingual access, mobile access, low-bandwidth access, and disability inclusion review where applicable.

9.4.9.2 Accessibility status shall be recorded and correctable. Known limitations shall be disclosed, prioritized, corrected, or archived.

9.4.9.3 Accessibility Testing shall not create legal compliance determination by default, certification, warranty, procurement readiness, or deployment authorization.

### 9.4.10 Documentation Review.

9.4.10.1 Documentation Review shall verify that software documentation accurately describes purpose, scope, installation, configuration, dependencies, data use, AI use, security considerations, privacy considerations, public-safe limits, support class, release class, license, contribution rules, known issues, correction pathway, deprecation rules, and archive rules.

9.4.10.2 Documentation shall avoid overclaiming readiness, security, certification, public authority relevance, finance relevance, procurement relevance, deployment status, or execution status.

9.4.10.3 Documentation Review shall not create approval, certification, warranty, legal advice, procurement status, financeability, or deployment authorization.

### 9.4.11 Reproducibility Review.

9.4.11.1 Reproducibility Review shall assess whether software objects, notebooks, data pipelines, models, benchmarks, dashboards, Studio workflows, and Reports evidence can be reproduced within stated scope, environment, dependencies, data access conditions, and limitations.

9.4.11.2 Reproducibility Review shall record environment, inputs, outputs, versions, limitations, missing dependencies, data restrictions, AI-use conditions, public-safe restrictions, and correction pathway.

9.4.11.3 Reproducibility shall not create truth certainty, certification, warranty, public authority approval, financeability, procurement readiness, deployment authorization, or execution.

### 9.4.12 Release Notes.

9.4.12.1 Release Notes shall accompany material software releases and shall identify version, date, changes, fixes, dependencies, known issues, security notes, data or AI changes where applicable, public-safe implications, support class, release class, compatibility notes, deprecation notices, correction notices, and archive links.

9.4.12.2 Release Notes shall be public-safe and shall avoid exposing harmful security detail, protected knowledge, sensitive data, or misleading readiness claims.

9.4.12.3 Release Notes shall not create warranty, approval, certification, procurement status, financeability, insurance approval, deployment authorization, or execution.

## 9.5 Software Metrics

### 9.5.1 Public-Good Usefulness.

9.5.1.1 Public-Good Usefulness shall measure the degree to which software supports Nexus purposes, including learning, evidence, public-safe reporting, observability, risk intelligence, National Portfolio formation, Foundry production, Studio workflows, Reports publication, Marketplace discovery, Registry status truth, Grid inputs, TRL notes, Nexus Universe readiness, Rails routing, Network memory, and lawful handoff dependency clarity.

9.5.1.2 Usefulness metrics may include active reuse, number of supported Nexus pathways, public-safe outputs enabled, National Portfolio relevance, Academy relevance, Foundry relevance, Studio relevance, documentation completeness, accessibility, localization, correction history, and support status.

9.5.1.3 Usefulness metrics shall not be rankings, procurement signals, provider validation, finance signals, public authority scores, certification, or deployment authority.

### 9.5.2 Evidence Quality.

9.5.2.1 Evidence Quality shall measure how well a software object documents purpose, scope, method, assumptions, dependencies, test results, data basis, AI-use basis, security status, limitations, review status, and correction pathway.

9.5.2.2 Evidence Quality may inform Registry status, Marketplace listing quality, Grid input, TRL notes, Reports, Studio use, Nexus Universe presentation, National Portfolio memory, and handoff dependency packages.

9.5.2.3 Evidence Quality shall not create certification, approval, warranty, financeability, procurement readiness, public authority decision, or deployment authorization.

### 9.5.3 Reuse Quality.

9.5.3.1 Reuse Quality shall measure whether software can be understood, installed, tested, adapted, localized, extended, forked, documented, integrated, corrected, and archived within its stated scope and release class.

9.5.3.2 Reuse Quality may consider modularity, API clarity, documentation, license clarity, dependency clarity, configuration safety, test coverage, portability, accessibility, localization, support class, and correction record.

9.5.3.3 Reuse Quality shall not imply universal fitness, production readiness, warranty, procurement readiness, financeability, or deployment authorization.

### 9.5.4 Security Status.

9.5.4.1 Security Status shall record security controls applied to a software object, including code review, dependency scanning, secret scanning, SBOM status, vulnerability disclosure status, threat modeling status, secure defaults, incident history, known vulnerabilities, remediation status, and support status.

9.5.4.2 Security Status shall be versioned, correctable, and linked to release class. Security Status may trigger restriction, suspension, withdrawal, recall, public-safe notice, Registry update, Marketplace action, or archive.

9.5.4.3 Security Status shall not create security certification, warranty, legal compliance determination, public authority approval, deployment authorization, or execution.

### 9.5.5 Accessibility Status.

9.5.5.1 Accessibility Status shall record the accessibility review and support condition of software objects, including user interfaces, dashboards, documentation, learning tools, Campaign tools, Reports tools, Marketplace interfaces, Registry interfaces, and Studio interfaces.

9.5.5.2 Accessibility Status may identify supported accessibility features, known barriers, language limitations, low-bandwidth limitations, mobile limitations, correction priorities, and archive status.

9.5.5.3 Accessibility Status shall not create legal compliance determination by default, certification, warranty, procurement status, or deployment authorization.

### 9.5.6 Documentation Quality.

9.5.6.1 Documentation Quality shall measure completeness, accuracy, clarity, public-safe wording, installation guidance, configuration guidance, usage guidance, limitations, support class, release class, data and AI labels, security notes, privacy notes, license notes, contribution rules, correction pathway, and archive rules.

9.5.6.2 Documentation Quality may affect release class, Marketplace eligibility, Registry completeness, Academy use, Studio use, Grid input, TRL note, and handoff dependency clarity.

9.5.6.3 Documentation Quality shall not create approval, warranty, certification, legal advice, procurement status, financeability, or deployment authorization.

### 9.5.7 Support Status.

9.5.7.1 Support Status metrics shall record whether a software object is supported, by whom, within what scope, for what duration, under what release class, through what channels, and with what security, documentation, accessibility, localization, and correction expectations.

9.5.7.2 Support Status may include known issues, response history, maintenance frequency, active maintainer count, dependency freshness, security responsiveness, deprecation schedule, and archive readiness.

9.5.7.3 Support Status shall not create service-level guarantee, warranty, procurement status, financeability, public authority approval, deployment authorization, or execution.

### 9.5.8 Correction History.

9.5.8.1 Correction History shall record patches, bug fixes, security fixes, documentation corrections, license corrections, attribution corrections, data removals, AI-use corrections, public-safe corrections, accessibility corrections, deprecations, suspensions, withdrawals, recalls, reinstatements, archive actions, and non-continuation actions.

9.5.8.2 Correction History shall be treated as an indicator of trust discipline. A strong correction record may improve confidence in lifecycle governance; it shall not erase underlying limitations or create certification.

9.5.8.3 Correction History shall be linked to Registry records, Marketplace listings, Reports, Studio workflows, Grid inputs, TRL notes, Nexus Universe materials, National Portfolio objects, and handoff dependency packages where affected.

### 9.5.9 Marketplace Discovery.

9.5.9.1 Marketplace Discovery metrics shall assess whether software objects are findable, understandable, accurately described, properly categorized, linked to Registry status, supported by metadata, bounded by notices, and accessible within their release and support class.

9.5.9.2 Discovery may consider searchability, metadata completeness, category accuracy, documentation links, version clarity, license clarity, support status, public-safe notes, and correction status.

9.5.9.3 Marketplace Discovery shall not create endorsement, procurement recommendation, provider validation, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 9.5.10 Registry Status.

9.5.10.1 Registry Status shall preserve status truth for software objects, including draft, active, under review, public-safe, controlled, supported, unsupported, deprecated, suspended, withdrawn, recalled, superseded, archived, or non-continuing.

9.5.10.2 Registry Status shall be versioned, evidence-linked where appropriate, support-linked, correction-linked, release-class-linked, and archive-linked.

9.5.10.3 Registry Status shall not create certification, approval, provider validation, procurement status, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

## 9.6 Software Boundaries

### 9.6.1 Software Release Is Not Warranty.

9.6.1.1 No release of software under NAF, whether draft, internal review, sandbox, Studio-only, secure-room-only, data-room-only, controlled public, public-safe summary, open public, Marketplace candidate, Registry-recorded, Nexus Universe-ready, handoff-recipient-only, archived, or non-continuing, shall create warranty by implication.

9.6.1.2 Users and lawful recipients shall remain responsible for independent review, configuration, testing, security assessment, legal assessment, operational assessment, public authority approvals where required, procurement processes where required, finance and insurance decisions where relevant, and deployment responsibility.

### 9.6.2 Reference Implementation Is Not Production Approval.

9.6.2.1 A Reference Implementation shall demonstrate a method, pattern, protocol, schema, workflow, interface, data flow, dashboard, model evaluation, Studio workflow, or handoff package structure within stated scope. It shall not be treated as production-ready by default.

9.6.2.2 Production use requires separate engineering, security review, privacy review, data rights, operational controls, support arrangements, legal authority, public authority approvals where required, procurement approvals where required, finance or insurance decisions where relevant, and recipient accountability.

### 9.6.3 Open-Source Availability Is Not Deployment Authorization.

9.6.3.1 Open-source availability shall mean that code or related materials are available under stated license and release conditions. It shall not authorize deployment, integration, operation, public authority use, procurement, finance, insurance, or operational reliance.

9.6.3.2 Open availability shall not override data restrictions, protected knowledge restrictions, AI-use restrictions, cyber-sensitive restrictions, export-control awareness, privacy obligations, community safeguards, Indigenous protocols where applicable, or release-class limits.

### 9.6.4 Code Review Is Not Security Certification.

9.6.4.1 Code Review is a quality and risk control. It shall not be represented as security certification, legal compliance determination, public authority approval, procurement approval, financeability, insurance approval, deployment authorization, or execution.

9.6.4.2 Security certification, where required, must be conducted separately by competent actors under applicable standards, legal frameworks, contractual requirements, or public authority processes outside NAF’s default software posture.

### 9.6.5 Marketplace Listing Is Not Procurement Recommendation.

9.6.5.1 Marketplace Listing of software shall mean that the object is discoverable under stated metadata, release class, support class, Registry status, license, boundary notices, and correction pathway. Listing shall not be treated as procurement recommendation, supplier approval, preferred vendor status, tender qualification, or purchasing instruction.

9.6.5.2 Procurement decisions remain the responsibility of competent procurement actors and must occur through separate lawful processes, independent diligence, conflict controls, competition controls, and jurisdiction-specific requirements.

### 9.6.6 Provider Contribution Is Not Provider Validation.

9.6.6.1 Provider Contribution to software, including code, tools, infrastructure, cloud credits, compute support, documentation, test environments, expertise, integrations, APIs, datasets, or support, shall be recorded as contribution only unless a separate lawful record states otherwise.

9.6.6.2 Provider Contribution shall not validate the provider, certify the provider’s technology, create preferred status, create procurement status, create financeability, create insurance approval, create public authority approval, authorize deployment, or imply Nexus endorsement.

9.6.6.3 The final software rule of Part IX is that NAF software may be powerful, reusable, open-source-capable, enterprise-grade, secure-by-design, evidence-bearing, standards-aware, and handoff-relevant, but it shall remain bounded by records, release class, support class, review gates, public-safe status, Registry truth, Marketplace notices, correctionability, archive, and lawful handoff discipline. No software object, repository, library, service, application, dashboard, API, SDK, connector, adapter, notebook, infrastructure template, test suite, reference implementation, code review, support class, Marketplace listing, Registry record, Nexus Universe demonstration, Grid input, TRL note, or handoff dependency package shall become warranty, certification, procurement recommendation, financeability, insurance approval, public authority approval, consent, deployment authorization, operation, command, agency, employment, or execution by implication.


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/operations/frameworks/nexus-agile-framework-naf/ix.-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.