# IX. SOFTWARE

This section defines software in Nexus as a governed public-good object.

It explains how software is created, reviewed, released, supported, corrected, archived, and handed off. It also sets the core boundary rule: software may support learning, evidence, workflows, and interoperability, but it does not become certification, procurement, deployment, public authority action, or execution by implication.

## 9.1 Public-Good Software Doctrine

### 9.1.1 Software as Public-Good Object

Public-good software is a governed Nexus object. It may include code, repositories, packages, scripts, notebooks, dashboards, APIs, connectors, SDKs, command-line tools, services, infrastructure-as-code, schemas, automation workflows, test suites, reference implementations, public-good technical baselines, Studio components, Observatory components, DICE components, GRIx components, DRI components, Academy components, Campaign components, Marketplace components, Registry components, Grid components, National Portfolio components, Nexus Universe components, and handoff-context components.

Public-good software is not merely “open code.” Within Nexus, software becomes a public-good object only when it carries identity, metadata, version, steward, source pathway, license class, support class, access class, review status, public-safe status, data-use label, AI-use label where applicable, dependency profile, security status, correction pathway, archive rule, and no-conversion notices. A repository without object discipline is a file location, not a mature Nexus software object.

Public-good software may support public authority learning, risk intelligence, observability, data governance, AI review, Studio workflows, digital twins, simulations, public-safe reporting, Academy pathways, Campaigns, Foundry builds, Marketplace discovery, Registry status truth, Grid and TRL review, Nexus Universe surge, National Portfolio preparation, and lawful handoff context. Its public-good character arises from its role in shared capability, evidence, learning, transparency, reuse, and correction, not from any claim that software alone can solve institutional, legal, financial, public authority, community, or operational dependencies.

A public-good software object does not certify itself, validate its contributors, approve its provider, bind its sponsor, procure its use, authorize deployment, create financeability, create insurability, grant consent, issue public authority action, or execute implementation by existing, being open, being listed, being demonstrated, being supported, or being handed off.

### 9.1.2 Software as Evidence-Bearing Capability

Public-good software should be treated as evidence-bearing capability. It can show how a method works, how a dataset may be transformed, how an API can connect systems, how a dashboard may display signals, how a Studio workflow may run, how a model may be evaluated, how a DRI indicator may be calculated, how a GRIx mapping may be structured, how an Observatory layer may be visualized, how a National Portfolio object may be assembled, or how a handoff package may be generated.

Software becomes evidence-bearing when its logic, inputs, outputs, assumptions, dependencies, version, tests, limitations, runtime conditions, data-use conditions, AI-use conditions, security controls, and review status are recorded. A working script is not enough. The object should make clear what it demonstrates, what it depends on, what has been reviewed, what remains uncertain, what it must not be used for, and how it can be corrected.

Evidence-bearing software may produce:

1. execution notes, identifying how the software was run and under what conditions;
2. provenance notes, identifying sources, contributors, repositories, versions, dependencies, and inputs;
3. test records, identifying what was tested and what was not;
4. benchmark records, where applicable and bounded;
5. data-use records, where data is processed, transformed, displayed, or stored;
6. AI-use records, where AI assists generation, classification, summarization, evaluation, simulation, or agentic workflow;
7. review records, including code, method, cyber, privacy, public-safe, AI, data, and safeguard review where relevant;
8. proof receipts, where contribution, review, release, correction, or archive events need durable traceability.

Software evidence is bounded. It may support learning, reproducibility where possible, review, maturity input, public-safe publication, or handoff context. It does not create absolute proof, legal compliance, safety certification, procurement approval, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority.

### 9.1.3 Software as Workflow, Not Authority

Public-good software is a workflow, not authority. It may automate steps, structure records, process data, generate summaries, run analyses, display dashboards, support Studio simulations, route Dockets, format Reports, update metadata, prepare Marketplace listings, assist Registry status views, generate Grid inputs, support Nexus Universe rooms, or assemble handoff packages. None of those workflow functions converts software into a decision-maker by default.

Software may support institutional judgment, but it must not silently replace it. A dashboard workflow is not a public authority decision. A classification script is not certification. A Grid calculation is not financeability. A DRI processing workflow is not public warning. A model-evaluation tool is not AI approval. A handoff-package generator is not execution authorization. A Marketplace listing workflow is not procurement.

Software workflows should include controls for:

1. human review where judgment is required;
2. no-command rules where operational effects could be inferred;
3. no-write-back rules where downstream systems could be altered;
4. no-autonomous-publication rules where public-safe review is required;
5. no-autonomous-handoff rules where recipient responsibility is required;
6. no-procurement-action rules;
7. no-finance-action rules;
8. no-public-authority-action rules;
9. no-consent-substitution rules;
10. correction, shutdown, rollback, recall, and archive pathways.

The governing principle is direct: software may move information, generate records, support analysis, improve learning, and prepare context; it does not decide, approve, procure, finance, insure, consent, deploy, command, or execute unless a separate competent actor lawfully configures and assumes responsibility for that function outside Nexus’s default public-good posture.

### 9.1.4 Open Technical Baseline

An open technical baseline is a public-good software object or object family that provides a reusable, inspectable, documented, versioned, and correctionable starting point for common Nexus workflows. It may include reference code, schemas, APIs, data models, dashboard patterns, notebook templates, DICE patterns, GRIx mappings, DRI calculation patterns, Observatory connectors, Studio workflow patterns, public-safe reporting templates, Registry schemas, Marketplace listing schemas, Grid and TRL record schemas, Academy templates, Nexus Universe build patterns, and handoff-package templates.

An open technical baseline should provide:

1. clear object identity, version, steward, repository, and license;
2. documented purpose, scope, intended use, and prohibited use;
3. installation and runtime instructions, including dependencies and environment requirements;
4. security notes, including secret handling, access control, vulnerability reporting, and dependency management;
5. data-use and AI-use labels, where relevant;
6. test and review notes, including what has been tested and what remains unreviewed;
7. public-safe language, where the baseline produces public-facing outputs;
8. extension guidance, explaining how downstream actors may adapt the baseline without claiming Nexus approval;
9. correction and archive rules, including deprecation, withdrawal, recall, supersession, and non-continuation.

An open technical baseline is not a standard by default, not a certified implementation, not a procurement specification, not an operational requirement, and not a deployment authorization. It is a shared public-good starting point. Competent actors may adapt it, review it, localize it, secure it, contract around it, deploy it, or certify a derivative through separate lawful processes. The baseline itself remains a public-good object with recorded limits.

### 9.1.5 Reference Implementation

A reference implementation is a software object that demonstrates one plausible way to implement a method, schema, API, workflow, dashboard, DRI process, GRIx mapping, Studio workflow, data transformation, public-safe reporting process, Registry function, Marketplace function, Grid or TRL record process, or handoff-package pattern.

A reference implementation should show how the underlying concept may be made operational in controlled form. It should be readable, documented, testable where possible, versioned, licensed, and bounded. It may be used for learning, review, prototyping, comparison, adaptation, Nexus Universe demonstration, Foundry development, Studio readiness, Academy teaching, Reports support, Marketplace discovery, Registry status truth, Grid maturity input, or handoff context.

A reference implementation should include:

1. implementation scope;
2. non-goals and prohibited use;
3. dependency list;
4. input and output specification;
5. sample data or synthetic data where appropriate;
6. data-use and AI-use labels;
7. test coverage and known limitations;
8. security and privacy notes;
9. public-safe status where outputs may be displayed;
10. support class;
11. correction, deprecation, withdrawal, recall, and archive pathway.

A reference implementation is not the only acceptable implementation unless a separate competent standard, contract, procurement, public authority process, or technical authority says so. It does not certify itself or others. It does not create preferred-provider status. It does not authorize deployment. It demonstrates a pattern under recorded limits.

### 9.1.6 Software as Reusable Learning Object

Public-good software may function as a reusable learning object. Code, notebooks, APIs, dashboards, test suites, schemas, model-evaluation tools, Studio workflows, DRI scripts, GRIx mappings, DICE patterns, Registry schemas, Marketplace listing tools, and handoff-package templates can teach participants how Nexus methods work and how public-good objects should be produced, reviewed, corrected, supported, and archived.

As a learning object, software should support:

1. Nexus Academy learning pathways;
2. Risk Academy learning pathways;
3. Foundry contributor learning;
4. Studio learning;
5. data and AI learning;
6. cyber and secure-release learning;
7. public-safe reporting learning;
8. National Portfolio learning;
9. public authority learning literacy;
10. finance-readiness and insurance-readiness literacy where software supports readiness context;
11. handoff literacy;
12. maintainer and reviewer training.

Software used as a learning object should include explanatory documentation, comments where useful, sample workflows, safe sample data, limitations, exercises, review prompts, public-safe notices, and no-conversion language. Learning use should not require access to restricted data unless a controlled room, synthetic data substitute, or compute-to-data environment is used.

Software learning is not professional licensing, employment qualification, procurement qualification, provider certification, public authority status, deployment authorization, or execution authority. It creates capability. It does not create external entitlement.

### 9.1.7 Software as Studio-Ready Component

Public-good software may be designed as a Studio-ready component when it can be safely used within Nexus Studio for controlled runtime workflows, dashboards, digital twins, simulations, AI review, data-room workflows, secure-room workflows, clean-room workflows, public authority learning workflows, readiness workflows, Nexus Universe demonstrations, or handoff demonstration workflows.

A Studio-ready software component should identify:

1. Studio workflow purpose;
2. input and output objects;
3. runtime environment;
4. access controls;
5. data-use and AI-use limits;
6. no-download, no-write-back, no-command, and output-review rules where required;
7. logging and audit requirements;
8. public-safe display limits;
9. cyber and privacy controls;
10. failure modes and shutdown controls;
11. correction, rollback, recall, and archive pathway;
12. no-decision and no-deployment notices.

Studio-ready status does not mean deployment-ready. It means the software may be used in a controlled runtime environment for learning, review, demonstration, readiness assessment, or handoff-context understanding. A Studio-ready dashboard is not an operational dashboard. A Studio-ready model is not an approved model. A Studio-ready simulation is not an official forecast. A Studio-ready workflow is not public authority action, procurement, finance, insurance, consent, deployment, or execution.

Studio readiness is controlled usability, not operational authority.

### 9.1.8 Software as Handoff Context

Public-good software may become handoff context when it is included in or supports a package transferred to a separate competent actor for independent review, evaluation, adaptation, procurement consideration, public authority procedure, finance or insurance diligence, donor review, research continuation, enterprise development, national implementation planning, or lawful operational consideration.

Software handoff context may include:

1. repository links or release packages;
2. installation instructions;
3. dependency lists;
4. architecture notes;
5. API documentation;
6. data-use and AI-use records;
7. security notes;
8. test records;
9. support and maintainer status;
10. license and rights terms;
11. public-safe limits;
12. Grid and TRL context;
13. Studio demonstration records;
14. known issues and unresolved dependencies;
15. correction and recall instructions;
16. recipient responsibility notices.

A software handoff package should make clear what the recipient receives and what the recipient does not receive. The recipient may receive code, documentation, records, dependency context, review notes, support state, and correction obligations. The recipient does not receive certification, procurement approval, finance approval, insurance approval, public authority approval, consent, deployment authorization, warranty, operational command, or execution authority from Nexus by default.

Software handoff context must preserve recipient responsibility. Any downstream use requires independent technical review, security review, legal review, data rights review, AI-use review, public authority approval where required, procurement where required, finance and insurance where required, safeguards where required, consent where required, operations, maintenance, incident response, and liability arrangements.

### 9.1.9 Software Without Warranty

Public-good software is provided under software without warranty unless a separate competent lawful instrument expressly provides otherwise. Nexus software may be useful, reviewed within scope, supported within scope, documented, tested, open, listed, registered, Studio-ready, Nexus Universe-presented, or handoff-relevant. None of those conditions creates a warranty by implication.

Software without warranty means:

1. code is not guaranteed to be error-free;
2. documentation is not guaranteed to be complete;
3. dependencies are not guaranteed to remain secure or available;
4. test coverage is not proof of fitness for all uses;
5. review status is not warranty;
6. support status is not service-level commitment unless separately contracted;
7. open release is not operational assurance;
8. reference implementation is not production guarantee;
9. Studio demonstration is not deployment warranty;
10. handoff package is not recipient reliance guarantee.

A No-Warranty Notice should be visible in repositories, documentation, release notes, Marketplace listings, Registry records, Studio workflow notes, Grid records, Reports, Academy materials, Nexus Universe materials, and handoff packages where software may be reused.

Any warranty, indemnity, service-level agreement, maintenance commitment, support obligation, production guarantee, professional sign-off, or operational assurance must be created separately by a competent actor through a contract or other lawful instrument. Nexus public-good software should be honest about its limits so that useful reuse does not become unsafe reliance.

### 9.1.10 Software Without Procurement or Deployment Implication

Public-good software operates under the doctrine of software without procurement or deployment implication. A software object may be open, listed, registered, demonstrated, reviewed, supported, contributed by a provider, supported by a sponsor, used in Studio, presented at Nexus Universe, included in a National Portfolio, classified by Grid or TRL, or included in a handoff package. None of those facts means the software has been procured, selected, approved for deployment, or authorized for operational use.

Software without procurement or deployment implication means:

1. Marketplace listing is not procurement;
2. Registry status is not certification;
3. Grid or TRL status is not deployment clearance;
4. Studio-ready status is not live-use approval;
5. Nexus Universe demonstration is not endorsement;
6. provider contribution is not provider validation;
7. sponsor support is not sponsor control;
8. public authority learning use is not public authority adoption;
9. National Portfolio inclusion is not government approval;
10. handoff context is not implementation authorization.

Procurement belongs to competent procuring actors. Deployment belongs to competent operating actors. Public authority use belongs to competent public authorities. Finance and insurance belong to separate competent capital, finance, donor, insurance, and public finance actors. Community and Indigenous consent where applicable belong to the proper consent holders and governance processes. Nexus software may inform, teach, demonstrate, and prepare; it does not decide.

The final Public-Good Software Doctrine rule is: software is a governed public-good object; it can carry evidence, methods, learning, workflows, Studio readiness, technical baselines, reference implementations, and handoff context; it must remain versioned, reviewed, supported where applicable, secured, corrected, and archived; it never becomes certification, warranty, procurement, finance, public authority action, consent, deployment, or execution by implication.

## 9.2 Software Object Classes

### 9.2.1 Repositories

Repositories are governed software object containers used to store, version, review, document, release, correct, and archive Nexus software objects and related materials. A repository may contain source code, documentation, issue records, pull requests, tests, notebooks, schemas, APIs, dashboards, models, configuration files, infrastructure-as-code, release packages, security notices, contribution guidelines, licenses, changelogs, correction notices, and archive records.

A Nexus repository should not be treated as a mere storage location. It should function as a governed record environment with clear object identity, steward, maintainer, license class, contribution terms, branch discipline, release discipline, security controls, dependency controls, review pathways, public-safe notices, support class, correction pathway, and archive rule.

A repository should identify:

1. repository purpose, including whether it supports public-good software, reference implementation, Studio workflow, DICE object, GRIx mapping, DRI workflow, Observatory connector, Academy object, Campaign object, Grid tool, Marketplace tool, Registry tool, Nexus Universe output, National Portfolio object, or handoff context;
2. repository steward and maintainers, including scope of responsibility, maintainer replacement pathway, escalation rules, and support boundaries;
3. license and contribution terms, including contributor rights, attribution, reuse conditions, third-party dependencies, provider contributions, sponsor-supported contributions, and restricted materials;
4. security and access controls, including branch protection, secret handling, credential controls, vulnerability disclosure, dependency review, release review, and incident handling;
5. release and correction discipline, including versioning, changelogs, release notes, deprecation, suspension, withdrawal, recall, supersession, archive, and non-continuation.

Repository visibility is not certification. A public repository is not an approved product. A private repository is not necessarily secure. A provider-contributed repository is not provider validation. A sponsor-supported repository is not sponsor control. A repository is a governed software memory and collaboration surface; it does not procure, finance, insure, approve, consent, deploy, or execute by implication.

### 9.2.2 Libraries

Libraries are reusable software components that provide functions, methods, utilities, data transformations, model interfaces, API helpers, visualization functions, schema validators, DICE utilities, GRIx mapping utilities, DRI indicator utilities, Observatory processing utilities, Studio workflow utilities, Grid and TRL utilities, Registry utilities, Marketplace utilities, Academy tools, or handoff-package helpers.

A Nexus library should be designed for reuse without ambiguity. It should identify what it does, what it does not do, what inputs it accepts, what outputs it produces, what dependencies it requires, what data-use and AI-use restrictions apply, what review has occurred, what support exists, and what risks may arise from misuse.

A library object should include:

1. package identity, version, repository, steward, maintainer, and release notes;
2. function scope, including supported functions, unsupported functions, assumptions, limitations, and prohibited uses;
3. dependency profile, including third-party packages, licenses, vulnerabilities, runtime requirements, model dependencies, data dependencies, and API dependencies;
4. test and review status, including unit tests, integration tests, security review, data review, AI review where applicable, and public-safe review where outputs may be displayed;
5. support and lifecycle status, including maintained, conditionally supported, unsupported, deprecated, suspended, withdrawn, recalled, superseded, archived, or non-continuing.

A library may be technically reusable without being operationally approved. Library use by a downstream actor requires independent assessment, integration, security review, legal review, data-rights review, and operational responsibility. Nexus library status does not create warranty, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority.

### 9.2.3 Services

Services are software objects that run as hosted, networked, containerized, cloud-based, edge-based, internal, controlled, restricted, Studio-linked, Registry-linked, Marketplace-linked, Observatory-linked, DICE-linked, API-linked, or handoff-related functions. A service may process requests, manage workflows, provide data access, run dashboards, support Studio runtime, host model inference, route Dockets, validate schemas, serve APIs, update Registry status, support Marketplace discovery, generate reports, manage learning records, or support secure-room and data-room workflows.

A Nexus service carries higher governance risk than static code because it may process live requests, handle data, connect systems, expose endpoints, or create reliance. A service should therefore have explicit runtime governance, monitoring, access control, security review, data-use and AI-use controls, incident handling, support status, and shutdown procedures.

A service object should identify:

1. service purpose and scope;
2. runtime environment, including cloud, edge, secure room, data room, clean room, National Node, Studio, internal environment, or handoff-recipient environment;
3. data processed, including data class, sensitivity, rights, privacy status, sovereignty conditions, and public-safe restrictions;
4. AI or model use, including model dependencies, human review, tool permissions, output restrictions, and prohibited uses;
5. access and security controls, including authentication, authorization, logging, monitoring, secrets, keys, rate limits, incident pathway, and vulnerability management;
6. operational boundaries, including no-public-authority-action, no-procurement-action, no-finance-action, no-consent-substitution, no-deployment-by-default, and no-execution-by-implication rules;
7. support and lifecycle controls, including maintenance, uptime expectations if any, correction, suspension, shutdown, withdrawal, recall, archive, and non-continuation.

A service may support public-good workflows but should not be mistaken for an operational authority. Service availability is not public authority approval. Service output is not a decision. Service integration is not procurement. Service use in Studio is not deployment authorization. Any production service operated by a separate competent actor must be governed by that actor’s lawful authority, contracts, security controls, data rights, support obligations, and liability arrangements.

### 9.2.4 Applications

Applications are user-facing or workflow-facing software objects that package functions, interfaces, services, dashboards, APIs, data workflows, AI workflows, learning workflows, reporting workflows, Registry views, Marketplace views, Studio workflows, National Portfolio tools, Nexus Universe tools, or handoff tools into a usable software product or environment.

A Nexus application may support public-good learning, public-safe reporting, Studio demonstrations, Observatory interpretation, DRI review, GRIx mapping, DICE governance, Foundry production, Academy delivery, Campaign participation, Registry status display, Marketplace discovery, Grid or TRL review, National Portfolio preparation, Nexus Universe activity, or lawful handoff context. It remains a public-good software object unless separately adopted, procured, deployed, operated, supported, financed, insured, or certified by a competent actor.

An application object should identify:

1. application purpose and user classes;
2. functional modules and workflows;
3. input and output objects;
4. data-use, AI-use, privacy, cyber, public-safe, and sensitivity controls;
5. access roles, including public, controlled, restricted, secure-room, National Node, Studio, reviewer, public authority learner, contributor, maintainer, or handoff-recipient roles;
6. user-interface boundary language, including no-decision, no-certification, no-procurement, no-finance, no-public-authority, no-consent, no-deployment, and no-execution notices;
7. support and incident controls, including maintenance, issue reporting, vulnerability reporting, correction, suspension, shutdown, recall, archive, and non-continuation.

A Nexus application may feel operational because it is usable. Usability must not be confused with authority. A working application is not a deployed system by default. A user-facing interface is not a decision system. Application output requires interpretation within its records, review state, public-safe status, and no-conversion boundaries.

### 9.2.5 Dashboards

Dashboards are software objects that visually display Nexus data, indicators, maps, metrics, signals, statuses, records, workflows, Campaign progress, Registry status, Marketplace listings, Grid and TRL context, DRI outputs, GRIx mappings, Observatory signals, Studio outputs, National Portfolio objects, Nexus Universe outputs, or handoff context.

A dashboard software object should be governed both as software and as communication. Its visual authority can easily exceed its evidentiary authority. The dashboard should therefore make sources, freshness, uncertainty, confidence, limitations, public-safe status, update cadence, sensitivity controls, and prohibited interpretations visible to users.

A dashboard object should identify:

1. dashboard purpose, including learning, public-safe display, DRI review, Observatory view, Studio workflow, Campaign monitoring, Registry view, Marketplace view, Grid view, National Portfolio view, Nexus Universe view, or handoff demonstration;
2. data and indicator sources, including provenance, update cadence, quality, uncertainty, missingness, and sensitivity;
3. visualization logic, including thresholds, colors, map layers, filters, aggregation, masking, geospatial generalization, and summary rules;
4. access and audience, including public-safe, controlled, restricted, secure-room, public authority learning, capital-reader, insurance-reader, donor-reader, National Node, Studio, or handoff-recipient access;
5. boundary notices, including dashboard-not-decision, no-public-warning, no-procurement, no-finance, no-insurance, no-certification, no-consent, no-deployment, and no-execution notices;
6. correction and recall controls, including data correction, map correction, indicator correction, public-safe correction, dashboard shutdown, archive, and non-continuation.

A dashboard is not a public warning, official classification, emergency command, public authority decision, procurement recommendation, finance decision, insurance decision, donor commitment, consent record, deployment authorization, or execution instruction. It is an interpretive surface that must remain tethered to status truth.

### 9.2.6 APIs

APIs are governed software interface objects that allow systems, repositories, dashboards, services, applications, Studio workflows, Registry records, Marketplace listings, Grid tools, Academy tools, Campaign tools, Observatory feeds, DRI workflows, GRIx mappings, DICE objects, National Portfolio tools, Nexus Universe tools, and handoff packages to exchange data, metadata, status, requests, outputs, or records.

A Nexus API should be treated as a controlled entry point, not merely a technical convenience. APIs can move sensitive data, expose system state, trigger workflows, automate records, and create downstream reliance. Every API should therefore have clear access controls, documentation, rate limits, authentication, authorization, logging, data-use restrictions, AI-use restrictions, security controls, versioning, deprecation, incident response, and correction pathways.

An API object should identify:

1. API purpose and supported use cases;
2. endpoint inventory and version;
3. data exchanged, including sensitivity, rights, privacy, sovereignty, public-safe status, and permitted uses;
4. authentication and authorization model;
5. security controls, including keys, secrets, encryption, rate limits, monitoring, logging, vulnerability reporting, and incident handling;
6. terms of use, including license, access limits, no-scraping where applicable, no-AI-training where applicable, no-public-authority-action, no-procurement-action, no-finance-action, and no-execution rules;
7. lifecycle controls, including versioning, deprecation, breaking changes, withdrawal, recall, archive, and non-continuation.

API availability does not create data rights. API access does not create publication rights. API integration does not create procurement status. API output does not create public authority action, certification, financeability, insurability, consent, deployment authorization, or execution authority.

### 9.2.7 SDKs

SDKs are software development kits that help users, contributors, maintainers, National Nodes, Working Groups, Competence Cells, Studio participants, Foundry participants, Academy learners, or lawful recipients build against Nexus APIs, schemas, data models, dashboards, workflows, registries, marketplaces, DICE objects, GRIx mappings, DRI indicators, Observatory feeds, Grid records, or handoff packages.

An SDK may include libraries, clients, examples, templates, command-line tools, test utilities, documentation, notebooks, authentication helpers, schema validators, data transformation helpers, and sample workflows. SDKs improve adoption and developer productivity, but they also risk making integration seem approved.

An SDK object should identify:

1. SDK purpose and target user class;
2. supported APIs, schemas, services, and workflows;
3. installation and runtime requirements;
4. examples and sample data, including whether samples are synthetic, public-safe, controlled, or restricted;
5. security guidance, including key handling, secrets, permissions, logging, and safe integration;
6. data-use and AI-use limits, including prohibited uses and downstream responsibilities;
7. support and version status, including compatibility, maintenance, deprecation, withdrawal, recall, and archive;
8. boundary notices, including SDK-not-certification, SDK-not-procurement, SDK-not-deployment, and SDK-not-execution.

An SDK helps build integrations. It does not approve those integrations. Downstream users remain responsible for legal, technical, security, data, AI, public-safe, procurement, finance, insurance, consent, deployment, and operational review before use outside Nexus public-good contexts.

### 9.2.8 Connectors

Connectors are software objects that connect Nexus systems, external systems, repositories, data sources, APIs, sensors, dashboards, data rooms, secure rooms, clean rooms, Observatory feeds, DRI feeds, GRIx mappings, Studio workflows, Marketplace systems, Registry systems, Grid tools, Academy platforms, Campaign tools, National Node repositories, Nexus Universe systems, or handoff-recipient environments.

Connectors create high leverage and high risk because they move information between contexts. A connector may cross institutional, jurisdictional, security, privacy, data sovereignty, public authority, provider, sponsor, community, Indigenous protocol where applicable, or enterprise boundaries. It must therefore be governed with strict connection scope, access rules, data-use rules, AI-use rules, logging, security, and correction controls.

A connector object should identify:

1. source and destination systems;
2. data, metadata, event, object, or workflow exchanged;
3. connection purpose and prohibited uses;
4. authentication, authorization, key management, and secrets handling;
5. data-use, AI-use, privacy, sovereignty, public-safe, and sensitivity restrictions;
6. write permissions or no-write-back rules;
7. logging, audit, monitoring, failure handling, and incident response;
8. support status and maintainer responsibility;
9. correction, disconnection, suspension, withdrawal, recall, archive, and non-continuation pathway.

A connector should not silently become a control channel. Connecting systems does not transfer authority. A connector to a public authority system is not public authority action. A connector to a provider system is not provider validation. A connector to a finance or insurance environment is not transaction execution. A connector to community data is not consent. Connector governance must prevent connection from becoming unrecorded power.

### 9.2.9 Adapters

Adapters are software objects that translate, normalize, transform, map, wrap, or mediate between different formats, schemas, APIs, data models, ontologies, systems, repositories, dashboards, workflows, languages, or technical environments. Adapters help Nexus preserve interoperability without requiring every system to be rebuilt around a single technology stack.

Adapters may support:

1. schema transformation;
2. API compatibility;
3. file format conversion;
4. metadata mapping;
5. ontology alignment;
6. GRIx mapping;
7. DRI indicator transformation;
8. Observatory data normalization;
9. Studio workflow compatibility;
10. Registry and Marketplace synchronization;
11. National Node localization;
12. handoff package formatting.

An adapter object should identify input format, output format, transformation logic, mappings, assumptions, loss of information, data-use implications, AI-use implications, sensitivity implications, validation rules, error handling, review status, support status, correction pathway, and archive rule.

Adapters can create hidden meaning changes. A field mapping may alter interpretation. A unit conversion may introduce error. A translation adapter may lose legal nuance. A schema adapter may drop sensitivity labels. Therefore, adapter governance must preserve transformation transparency and correction propagation.

An adapter does not validate either system. It enables compatibility within limits. Interoperability is not approval, certification, procurement, financeability, insurability, public authority action, consent, deployment, or execution.

### 9.2.10 Command-Line Tools

Command-line tools are software objects that allow users, contributors, maintainers, reviewers, National Nodes, Working Groups, Competence Cells, Studio operators, Foundry participants, repository maintainers, data stewards, or handoff preparers to run defined tasks through command-line interfaces.

Command-line tools may support data processing, schema validation, report generation, metadata updates, Registry record checks, Marketplace listing preparation, Grid record generation, DRI calculations, GRIx mapping, DICE validation, repository maintenance, testing, release packaging, public-safe transformation, archive processing, or handoff package assembly.

A command-line tool should identify:

1. tool purpose and commands;
2. inputs and outputs;
3. required permissions;
4. runtime environment and dependencies;
5. data-use and AI-use restrictions;
6. file-system and network behavior;
7. write, delete, publish, or handoff actions, including safeguards and confirmation requirements;
8. logging and audit behavior;
9. error handling and rollback;
10. support status, correction pathway, deprecation, withdrawal, recall, archive, and non-continuation.

Command-line tools can be powerful because they may alter files, publish outputs, update records, or package handoff materials. They should therefore include no-command or confirmation controls where accidental action could create unsafe consequences.

A CLI command is not authority. A command output is not a decision. A generated package is not handoff completion unless recorded. Command-line tools must remain within recorded user permissions and Nexus boundaries.

### 9.2.11 Notebooks

Notebooks are software objects that combine code, data references, narrative explanation, outputs, visualizations, methods, and learning context. They may be used for analysis, teaching, reproducibility, exploration, model evaluation, DRI calculation, GRIx mapping, Observatory workflows, Studio workflows, data quality review, AI review, public-safe transformation, Reports support, Academy exercises, Foundry builds, Grid inputs, or handoff context.

A notebook object should identify:

1. purpose, including learning, analysis, demonstration, review, public-safe transformation, or handoff context;
2. runtime environment, dependencies, kernel, package versions, and execution requirements;
3. input data and model dependencies;
4. data-use and AI-use labels;
5. output classification, including public-safe, controlled, restricted, secure-room-only, data-room-only, clean-room-only, archive-only, or non-continuing;
6. reproducibility status, including whether outputs can be reproduced and under what conditions;
7. review status, including method, data, AI, cyber, public-safe, and safeguard review where relevant;
8. support and correction status, including rerun requirements, stale output warnings, withdrawal, recall, archive, and non-continuation.

A notebook that executes is not a validated system. A chart in a notebook is not an official dashboard. A model result is not truth. A learning notebook is not professional certification. A handoff notebook is not execution authority. Notebook objects must clearly separate exploration, teaching, review, and operational use.

### 9.2.12 Templates

Templates are reusable software or document-structured objects that provide a starting form for reports, Dockets, records, schemas, metadata, code modules, notebooks, dashboards, Studio workflows, Campaign pages, Academy modules, Registry entries, Marketplace listings, Grid reviews, TRL records, National Portfolio objects, Nexus Universe outputs, support records, contribution records, review records, correction records, archive records, or handoff packages.

Templates support consistency and quality. They reduce cognitive load, improve interoperability, and help new contributors follow Nexus object discipline. They also create risk if users treat template completion as substantive review.

A template object should identify:

1. template purpose and object class;
2. required fields and optional fields;
3. controlled vocabulary and schema dependencies;
4. instructions and examples;
5. public-safe and boundary language;
6. data-use and AI-use placeholders;
7. review and sign-off requirements;
8. localization and accessibility requirements;
9. correction and versioning rules;
10. archive and non-continuation treatment.

A completed template is not automatically valid. Filling in a handoff template does not complete handoff. Filling in a Grid template does not certify readiness. Filling in a public authority learning template does not create public authority action. Templates structure records; they do not decide the truth of the content.

### 9.2.13 Infrastructure-as-Code

Infrastructure-as-code objects are software objects that define cloud resources, network resources, compute environments, storage, permissions, identity and access controls, secure rooms, data rooms, clean rooms, Studio runtime environments, Observatory infrastructure, deployment environments, testing environments, development environments, logging, monitoring, and security controls through code or configuration.

Infrastructure-as-code carries significant governance risk because it may create, modify, connect, expose, or destroy technical environments. It must be governed with strict review, access, secrets management, environment separation, change control, logging, rollback, and incident response.

An infrastructure-as-code object should identify:

1. infrastructure purpose and environment class, including development, testbed, Studio, secure room, data room, clean room, National Node, Nexus Universe, handoff-recipient, or archive environment;
2. resources created or modified;
3. permissions and identity controls;
4. network exposure and security groups;
5. data storage and data sovereignty implications;
6. logging, monitoring, backup, and incident controls;
7. secrets and key management;
8. approval and change-control requirements;
9. rollback, teardown, suspension, withdrawal, recall, and archive pathway.

Infrastructure-as-code in Nexus does not authorize deployment by default. A configuration may create a test environment or Studio environment, but it does not approve production operation. Any production infrastructure requires separate competent actor responsibility, security assurance, legal authority, procurement where required, finance where required, data rights, operational support, incident response, and liability arrangements.

### 9.2.14 Test Suites

Test suites are software objects used to examine whether software, APIs, schemas, models, data transformations, dashboards, notebooks, Studio workflows, DRI calculations, GRIx mappings, DICE validations, Registry functions, Marketplace functions, Grid utilities, or handoff-package tools behave as expected within defined scope.

Test suites may include unit tests, integration tests, regression tests, security tests, data-quality tests, schema-validation tests, API tests, model-evaluation tests, performance tests, accessibility tests, public-safe output tests, localization tests, and handoff-package completeness tests.

A test suite object should identify:

1. test scope, including what is tested and what is not tested;
2. test environment;
3. test data, including synthetic, public-safe, controlled, restricted, or secure-room data;
4. expected outputs;
5. pass, fail, skip, warning, and limitation meanings;
6. coverage limitations;
7. review and maintenance status;
8. security and privacy implications;
9. correction, regression, deprecation, archive, and non-continuation pathway.

Passing a test suite is not certification. It does not prove safety, legality, procurement readiness, financeability, insurability, public authority approval, consent, deployment authorization, or execution readiness. It shows that defined tests passed under defined conditions. The test suite itself may also be incomplete or require correction.

Testing is necessary for trust. It is not sufficient for authority.

### 9.2.15 Reference Implementations

Reference implementations are software object classes that demonstrate one documented way to implement a Nexus method, schema, API, workflow, dashboard, DRI process, GRIx mapping, DICE pattern, Observatory connector, Studio workflow, Registry function, Marketplace function, Grid or TRL process, Academy workflow, Campaign tool, National Portfolio tool, Nexus Universe tool, or handoff-package pattern.

A reference implementation should be designed to teach and demonstrate, not to monopolize implementation. It should include source code, documentation, examples, tests, known limitations, architecture notes, data-use labels, AI-use labels, license class, security notes, support class, review status, public-safe status, correction pathway, deprecation pathway, withdrawal pathway, recall pathway, and archive rule.

A reference implementation may support:

1. contributor learning;
2. method reproducibility where possible;
3. Studio demonstration;
4. Foundry build acceleration;
5. Academy teaching;
6. Reports documentation;
7. Grid and TRL maturity input;
8. Marketplace discovery;
9. Registry status truth;
10. National Portfolio preparation;
11. Nexus Universe Core Build;
12. lawful handoff context.

A reference implementation does not define the only acceptable implementation unless a separate competent standard, contract, procurement process, public authority process, or protocol authority expressly provides that effect. It is not certification, procurement approval, provider validation, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

The final Software Object Classes rule is: repositories preserve software memory; libraries enable reuse; services run controlled functions; applications package workflows; dashboards visualize context; APIs connect systems; SDKs support builders; connectors move between environments; adapters translate; command-line tools operate tasks; notebooks compute and teach; templates structure records; infrastructure-as-code defines environments; test suites check behavior; reference implementations demonstrate patterns; none of them certifies, procures, finances, insures, approves, consents, deploys, or executes by implication.

## 9.3 Repository and Release Governance

### 9.3.1 Repository Creation

Repository creation is the governed act by which a Nexus software object receives a formal development, collaboration, review, release, correction, and archive home. A repository should not be created merely because code exists. It should be created because a software object, reference implementation, dashboard, API, SDK, connector, notebook, template, infrastructure-as-code object, test suite, Studio component, DICE object, GRIx object, DRI object, Observatory component, Academy tool, Campaign tool, Marketplace tool, Registry tool, Grid tool, Nexus Universe output, National Portfolio object, or handoff-context component requires durable object governance.

A repository creation record should identify the repository’s purpose, object class, source pathway, steward, maintainer class, intended contributors, public-good role, access class, license class, support expectation, public-safe status, security posture, data-use relationship, AI-use relationship, dependency profile, release model, Marketplace eligibility, Registry requirement, Grid or TRL relationship where applicable, Nexus Universe relationship where applicable, and correction and archive pathway.

Repository creation should include baseline governance files and records, including a README, license file, contribution guide, code of conduct where appropriate, security policy, issue and vulnerability reporting pathway, maintainer file or equivalent steward record, release notes structure, changelog structure, dependency review approach, public-safe documentation notice, no-warranty notice, no-certification notice, no-procurement notice, no-deployment notice, no-execution notice, and provider/sponsor boundary notices where relevant.

A repository may be public, controlled, restricted, internal, secure-room-linked, data-room-linked, National Node-linked, handoff-recipient-linked, or archive-only depending on sensitivity and lifecycle state. Public repository creation does not make the software open for all use. Restricted repository creation does not exempt the repository from recordkeeping. Repository creation creates a governed software surface, not approval, procurement, finance, insurance, deployment, consent, or execution authority.

### 9.3.2 License Selection

License selection determines the legal terms under which a software repository, library, application, dashboard, API, SDK, connector, adapter, command-line tool, notebook, template, infrastructure-as-code object, test suite, or reference implementation may be copied, modified, redistributed, embedded, combined, displayed, taught, cited, forked, handed off, commercialized, or restricted.

License selection should be made before broad release, public listing, Nexus Universe presentation, Marketplace discovery, Registry status beyond early draft, or handoff-context transfer. Where early development requires temporary license uncertainty, the repository should carry a license-pending or restricted-use notice until the license is resolved.

License selection should consider:

1. public-good purpose, including whether the object is intended for open reuse, controlled reuse, research use, educational use, handoff-recipient use, or internal Nexus use;
2. third-party dependencies, including open-source licenses, commercial licenses, data-license restrictions, model-use restrictions, API terms, and incompatible license obligations;
3. contributor terms, including whether contributors retain copyright, grant license rights, sign contributor terms, or contribute through institutional arrangements;
4. data and AI dependencies, including whether code processes restricted data, uses models with restricted terms, generates outputs subject to AI-use limits, or includes sample data;
5. sponsor and provider contributions, including whether in-kind contributions create license, attribution, trademark, confidentiality, or support conditions;
6. handoff context, including whether lawful recipients may adapt the software and under what restrictions;
7. public-safe release, including whether license language must be paired with no-warranty, no-certification, no-procurement, no-deployment, and no-execution notices.

License selection does not resolve every use issue. A permissive software license does not grant data rights, AI-training rights, public authority approval, export-control clearance, protected knowledge permission, community consent, Indigenous consent where applicable, procurement approval, finance approval, insurance approval, deployment authorization, or execution authority. The license is one layer of permission; object metadata, data-use labels, AI-use labels, access class, sensitivity class, review status, and handoff records remain controlling for Nexus meaning.

### 9.3.3 Contribution Model

The contribution model defines how persons, teams, institutions, providers, sponsors, universities, National Nodes, Working Groups, Competence Cells, students, youth participants where safeguarded, public authority learners, community participants, Indigenous institutions where applicable, maintainers, reviewers, contractors, and lawful recipients may contribute to a Nexus repository.

A contribution model should define:

1. eligible contributors, including open contributors, controlled contributors, institutional contributors, provider contributors, sponsor-supported contributors, National Node contributors, Working Group contributors, Competence Cell contributors, Academy learners, Foundry contributors, Studio contributors, and handoff-recipient contributors;
2. contribution types, including code, tests, documentation, schemas, APIs, notebooks, templates, dashboards, data transformation scripts, AI review notes, security reports, accessibility improvements, localization, public-safe language, issue reports, bug fixes, vulnerability disclosures, and correction proposals;
3. submission methods, including issues, pull requests, patches, bounties, quests, maintainer submissions, controlled-room submissions, or handoff-recipient submissions;
4. review requirements, including code review, dependency review, security review, data-use review, AI-use review, public-safe review, accessibility review, and safeguard review where relevant;
5. rights and attribution, including license grant, contributor terms, attribution rules, confidentiality, restricted materials, and protected knowledge exclusions;
6. recognition records, including Contribution Records, Proof Receipts, iCRS entries, Learning Records, Review Records, and Maintainer Records where applicable;
7. boundary notices, including contribution without employment, provider contribution without validation, sponsor support without control, contribution without procurement, contribution without certification, contribution without deployment, and contribution without execution.

The contribution model should be generous enough to enable public-good production and disciplined enough to prevent unreviewed, unsafe, unclear, or rights-uncertain contributions. Contribution creates a record; it does not create ownership, employment, procurement preference, provider validation, public authority status, financeability, insurability, consent, deployment authorization, or execution authority by default.

### 9.3.4 Maintainer Assignment

Maintainer assignment records who is responsible for the repository’s continuity, review discipline, release discipline, security posture, issue handling, correction pathway, deprecation decisions, support classification, and archive transition. A repository without a maintainer may exist, but it should not be represented as actively supported.

Maintainer assignment should identify:

1. maintainer identity or maintainer class, including individual maintainer, maintainer team, Working Group, Competence Cell, National Node, institutional steward, Foundry pathway, Studio pathway, or repository steward;
2. maintainer scope, including code review, release management, documentation, issue triage, dependency updates, security response, public-safe documentation, Marketplace listing updates, Registry status updates, Grid and TRL input updates, and handoff package updates;
3. authority limits, including what maintainers may approve within the repository and what requires institutional, legal, security, public-safe, safeguard, finance-boundary, public authority-boundary, or handoff review;
4. conflict controls, including provider conflicts, sponsor conflicts, employment conflicts, institutional conflicts, procurement conflicts, and financial conflicts;
5. succession pathway, including replacement, resignation, inactivity, emergency transfer, suspension, and archive transition;
6. support relationship, including whether maintainer assignment creates active support, conditional support, community maintenance, National Node support, provider-supported-without-validation, sponsor-supported-without-control, or maintainer-needed status.

Maintainers steward the repository record. They do not certify the software, approve deployment, bind Nexus institutions, select suppliers, conduct procurement, provide investment advice, underwrite insurance, grant consent, issue public authority action, or execute projects by default. Maintainer authority must remain bounded by repository governance and Nexus no-conversion principles.

### 9.3.5 Code of Conduct

A code of conduct defines expected behavior for repository contributors, maintainers, reviewers, issue participants, provider contributors, sponsor-supported participants, learners, students, youth participants where applicable, public authority learners, community participants, and other repository participants. It protects public-good collaboration from abuse, harassment, discrimination, intimidation, extraction, unsafe disclosure, role overclaim, and capture.

A repository code of conduct should address:

1. respectful participation;
2. anti-harassment and anti-discrimination expectations;
3. accessibility and inclusion;
4. youth and student safeguarding where relevant;
5. community and Indigenous protocol respect where applicable;
6. protected knowledge and confidentiality discipline;
7. privacy, cyber, and security disclosure discipline;
8. provider and sponsor boundary discipline;
9. public authority boundary discipline;
10. no-procurement, no-finance, no-certification, no-deployment, and no-execution overclaim;
11. issue escalation, enforcement, suspension, removal, and correction.

The code of conduct should apply to repository spaces, issue threads, pull requests, discussions, documentation comments, review meetings, Studio-linked workflows, Foundry-linked contribution pathways, Academy-linked learning pathways, Campaign-linked contribution pathways, Nexus Universe-linked repository activity, and handoff-context collaboration where applicable.

A code of conduct is not a replacement for employment law, public authority procedure, professional regulation, institutional policy, child protection law, human rights law, cybersecurity law, privacy law, or criminal law where applicable. It is a repository-level conduct instrument that supports safe public-good collaboration and preserves the conditions for trustworthy contribution.

### 9.3.6 Contribution Terms

Contribution terms define the legal, rights, attribution, confidentiality, licensing, recordkeeping, and boundary conditions under which contributions enter a Nexus repository. Contribution terms should be clear before contributions are accepted, merged, published, listed, registered, taught, demonstrated, or handed off.

Contribution terms should identify:

1. rights granted, including copyright license, patent license where applicable, documentation license, data rights where applicable, model-related rights where applicable, and contribution reuse permissions;
2. contributor representation, including that the contributor has authority to contribute, is not submitting prohibited confidential material, and will identify third-party restrictions;
3. attribution and recognition, including how contributors may be named, anonymized, institutionally attributed, or recorded through Contribution Records and Proof Receipts;
4. confidentiality and controlled materials, including what may not be submitted to open repositories and what requires secure-room, data-room, clean-room, protected-knowledge, or National Node controls;
5. data and AI conditions, including no unauthorized personal data, no unauthorized protected knowledge, no unauthorized AI-generated code where restricted, no prohibited training material, and disclosure of AI assistance where required;
6. review and acceptance, including that submission does not guarantee merge, recognition, support, payment, employment, procurement, certification, or endorsement;
7. correction and withdrawal, including correction of rights errors, license issues, security issues, public-safe issues, provider overclaims, sponsor overclaims, and protected knowledge exposure.

Contribution terms should distinguish contribution from employment, contracting, procurement, vendor qualification, public authority role, finance interest, insurance interest, consent, deployment authority, or execution authority. Where a contribution is paid, grant-funded, scholarship-supported, fellowship-linked, contractor-provided, or institutionally sponsored, the separate lawful instrument should govern those additional conditions.

### 9.3.7 Dependency Review

Dependency review is the process for identifying, assessing, monitoring, updating, replacing, restricting, or removing third-party code, packages, libraries, services, APIs, models, datasets, containers, infrastructure modules, notebooks, licenses, runtime environments, and transitive dependencies used by a Nexus repository.

Dependency review should examine:

1. license compatibility, including open-source license compatibility, attribution obligations, copyleft obligations, commercial restrictions, non-commercial restrictions, model-use restrictions, and data-use restrictions;
2. security posture, including known vulnerabilities, abandoned packages, malicious packages, dependency confusion, supply-chain risk, secrets exposure, and update cadence;
3. operational dependency, including whether the repository depends on hosted services, vendor APIs, provider platforms, cloud services, model endpoints, or proprietary tools;
4. data and AI dependency, including whether dependencies transmit data, process sensitive inputs, retain prompts, train on inputs, or create output restrictions;
5. public-good compatibility, including whether the dependency creates lock-in, restricts reuse, undermines public-safe release, creates national sovereignty concerns, or conflicts with handoff needs;
6. support implications, including who maintains the dependency, how updates are handled, what happens when the dependency is deprecated, and what correction pathway applies.

A Dependency Review Record should identify reviewed dependencies, risk level, license status, vulnerability status, update status, unresolved issues, replacement options, acceptance rationale, correction triggers, and archive implications.

Dependency review is not certification. It is supply-chain awareness. Passing dependency review does not make software safe for deployment, procurement-ready, financeable, insurable, publicly approved, consented, or executable. It allows the repository to proceed within recorded limits.

### 9.3.8 Security Review

Security review is the repository governance process for identifying and reducing cybersecurity, software supply-chain, access-control, secret-management, vulnerability, dependency, API, service, infrastructure, data, AI, and operational risks associated with a Nexus software object.

Security review may include:

1. repository access review;
2. branch protection and code-review controls;
3. secret scanning and key management;
4. dependency vulnerability review;
5. static and dynamic analysis where appropriate;
6. container and infrastructure review;
7. API authentication and authorization review;
8. logging, monitoring, and audit review;
9. data-handling and privacy review;
10. AI workflow security review, including prompt injection, tool permission, data leakage, and model dependency risks;
11. secure-room, data-room, clean-room, Studio, and handoff workflow review;
12. vulnerability disclosure and incident response pathways.

A Security Review Record should identify scope, tools or methods used, reviewer class, findings, severity, remediation actions, unresolved risks, release implications, public-safe implications, support implications, handoff implications, and correction pathway.

Security review must be repeated when dependencies change, access changes, architecture changes, public release changes, API exposure changes, data sensitivity changes, AI-use changes, support class changes, Studio use changes, Nexus Universe demonstration changes, or handoff context changes.

Security review is not security certification by default. It does not create warranty, compliance approval, procurement clearance, cyber insurance approval, deployment authorization, public authority approval, or execution authority. It creates bounded security context for repository governance.

### 9.3.9 Public-Safe Documentation

Public-safe documentation is repository documentation written so that users, contributors, reviewers, learners, public authority learners, Marketplace users, Registry users, Studio participants, National Nodes, Nexus Universe participants, and lawful handoff recipients can understand the software without being misled about its status, limits, risks, or authority.

Public-safe documentation should include:

1. purpose and scope, including what the software does and does not do;
2. installation and use instructions, including required environment and sample data conditions;
3. status labels, including draft, working, review-ready, public-safe open, controlled, restricted, supported, unsupported, deprecated, suspended, withdrawn, recalled, archive-only, or non-continuing;
4. data-use and AI-use labels, including prohibited inputs, prohibited outputs, and output review requirements;
5. security notes, including known risks, dependency status, vulnerability reporting, secrets handling, and safe configuration;
6. limitations, including known defects, assumptions, unsupported uses, non-goals, and uncertainty;
7. boundary notices, including no-certification, no-warranty, no-procurement, no-finance, no-public-authority, no-consent, no-deployment, no-execution, no-provider-validation, and no-sponsor-control notices where relevant;
8. support and correction pathway, including issue reporting, maintainer status, release notes, deprecation, withdrawal, recall, archive, and non-continuation.

Documentation should not market software beyond the record. It should not imply that a prototype is production-ready, that a dashboard is a decision tool, that an API is a permission grant, that a reference implementation is mandatory, that a provider contribution is validation, that sponsor support is control, or that Nexus status is certification.

Public-safe documentation is not cosmetic. It is a safety control.

### 9.3.10 Release Classification

Release classification determines the permitted release state of a repository version, package, binary, container, notebook, dashboard, API, service, template, infrastructure-as-code module, test suite, or reference implementation. It controls who may access the release, what it may be used for, what notices apply, and what review or support conditions govern it.

Release classes may include:

1. Internal Draft, for early work not ready for external use;
2. Controlled Review, for defined reviewers under access controls;
3. Public-Safe Open, for public release under no-warranty and no-conversion notices;
4. Public-Safe Controlled, for limited release to participants or institutions;
5. Restricted Release, for sensitive objects requiring controlled access;
6. Secure-Room-Only Release, for software or workflows requiring secure-room conditions;
7. Data-Room-Only Release, for controlled diligence or review contexts;
8. Clean-Room-Only Release, for computation without raw-data exposure;
9. Studio-Ready Release, for controlled runtime demonstration or review;
10. Nexus-Universe-Ready Release, for annual surge use under recorded conditions;
11. Marketplace-Discoverable Release, for discovery under Registry-linked status truth;
12. Handoff-Context Release, for lawful recipient review under Handoff Records;
13. Deprecated Release, for legacy access with warning;
14. Withdrawn or Recalled Release, for stop-use or recall conditions;
15. Archive-Only Release, for memory without current authority;
16. Non-Continuing Release, for releases that will not proceed absent separate revival.

Release classification should be tied to review status, support class, security review, dependency review, public-safe documentation, access class, Registry record, Marketplace eligibility, Grid or TRL status, and correction pathway.

A release class is not approval. Public release is not deployment authorization. Studio-ready is not production-ready. Marketplace-discoverable is not procurement. Handoff-context release is not execution. Release classification governs availability, not authority.

### 9.3.11 Marketplace Listing

Marketplace listing is the governed process by which a repository or software release becomes discoverable through Nexus Marketplace. A repository should not be listed merely because it exists. Listing should occur only when the software object has sufficient metadata, Registry relationship, public-safe documentation, support classification, license clarity, access class, review status, correction pathway, and no-conversion notices to be responsibly discoverable.

A software Marketplace listing should identify:

1. repository or release identity;
2. object class;
3. current version;
4. steward and maintainer status;
5. Registry status;
6. release class;
7. access class;
8. license class;
9. support class;
10. security and dependency review status;
11. data-use and AI-use labels;
12. public-safe documentation link;
13. intended use and prohibited use;
14. provider contribution and sponsor support notes where applicable;
15. Grid or TRL context where applicable;
16. Studio relationship where applicable;
17. Nexus Universe relationship where applicable;
18. handoff-context relationship where applicable;
19. correction and delisting pathway.

Marketplace listing is not procurement, provider validation, certification, endorsement, financeability, insurability, public authority approval, deployment authorization, or execution authority. The listing helps users discover software and understand its status. It must remain tethered to Registry truth and be corrected or delisted when status changes.

### 9.3.12 Registry Record

A Registry Record is required for any software repository or release that becomes materially used, reviewed, published, listed, Studio-ready, Nexus Universe-presented, Grid or TRL-classified, National Portfolio-linked, or handoff-relevant. The Registry Record provides the status truth for the software object.

A software Registry Record should identify:

1. software object identifier;
2. repository location;
3. release version;
4. object class;
5. steward;
6. maintainer and support class;
7. license class;
8. access class;
9. release class;
10. review status;
11. security review status;
12. dependency review status;
13. data-use and AI-use labels;
14. Marketplace listing relationship;
15. Studio relationship;
16. Grid or TRL relationship;
17. Nexus Universe relationship;
18. National Portfolio or handoff relationship where applicable;
19. correction, deprecation, withdrawal, recall, archive, and non-continuation status.

Registry Record status is not software certification. It is status truth. A Registry Record may show that software is supported, public-safe, Studio-ready, Marketplace-discoverable, or handoff-context-ready within scope. It does not make the software production-ready, procured, financed, insured, publicly approved, consented, deployed, or executable.

The Registry Record should be updated whenever release, support, security, dependency, review, license, public-safe, Marketplace, Studio, Grid, Nexus Universe, handoff, correction, or archive status changes.

### 9.3.13 Support Classification

Support classification records the support condition of a repository or release. It tells users whether the software is actively maintained, conditionally supported, sponsor-supported without sponsor control, provider-supported without provider validation, National Node-supported, community-maintained, maintainer-needed, unsupported, deprecated, suspended, withdrawn, recalled, archive-only, or non-continuing.

Support classification should identify:

1. support class;
2. maintainer or support steward;
3. support scope;
4. support duration;
5. issue handling process;
6. vulnerability handling process;
7. dependency update process;
8. documentation update process;
9. public-safe language update process;
10. release update process;
11. support dependencies, including funding, provider resources, sponsor resources, National Node capacity, community maintenance, or institutional support;
12. support expiry or review date;
13. correction, deprecation, withdrawal, recall, archive, or non-continuation triggers.

Support classification is not warranty, service-level agreement, operational guarantee, procurement approval, deployment authorization, financeability, insurability, public authority approval, or execution authority. A supported Nexus repository may still be experimental, learning-oriented, Studio-only, public-good-only, restricted, or handoff-context-only.

Support classification should be visible in repository documentation, Registry records, Marketplace listings, release notes, Studio documentation, Grid records, Nexus Universe materials, and handoff packages where relevant.

### 9.3.14 Correction

Correction is the repository and release governance process for addressing errors, defects, vulnerabilities, license issues, dependency issues, documentation errors, public-safe language errors, data-use errors, AI-use errors, access-control failures, provider or sponsor overclaims, Marketplace listing errors, Registry status errors, Grid or TRL misclassifications, Studio workflow issues, Nexus Universe output issues, National Portfolio references, or handoff package issues affecting software.

Repository correction may include:

1. code patch;
2. documentation correction;
3. dependency update;
4. security fix;
5. license correction;
6. metadata correction;
7. public-safe notice correction;
8. release note correction;
9. Registry status update;
10. Marketplace listing correction;
11. Studio workflow correction;
12. Grid or TRL correction;
13. support-status correction;
14. handoff package correction;
15. public repair notice where needed.

A software Correction Record should identify affected repository, affected release, correction trigger, severity, prior state, corrected state, affected users, affected downstream objects, affected Marketplace listings, affected Registry records, affected Studio workflows, affected Grid or TRL records, affected National Portfolio or Nexus Universe objects, affected handoff recipients, required notifications, and archive treatment.

Correction may require release of a patched version, suspension of the current release, withdrawal, recall, deprecation, delisting, or archive. Correction is not optional where continuing reliance would be unsafe or misleading. It is the mechanism that makes public-good software trustworthy over time.

### 9.3.15 Deprecation

Deprecation is the repository governance process for signaling that a software object, release, feature, API endpoint, library function, dashboard component, notebook, template, infrastructure module, test suite, connector, adapter, or reference implementation remains visible or usable within limits but is no longer preferred for new use.

Deprecation may be triggered by:

1. better successor release;
2. security issue;
3. dependency risk;
4. unsupported maintainer state;
5. outdated method;
6. changed data-use condition;
7. changed AI-use condition;
8. public-safe concern;
9. licensing issue;
10. API breaking change;
11. Studio workflow replacement;
12. Grid or TRL downgrade;
13. Marketplace delisting need;
14. Registry status update;
15. National Portfolio or Nexus Universe correction;
16. handoff dependency change.

A deprecation notice should identify the deprecated object or version, effective date, reason, successor object where applicable, migration guidance, permitted legacy use, prohibited new use, support end date, security implications, Marketplace and Registry implications, handoff implications, correction pathway, and archive rule.

Deprecation is not deletion. It is a public-good honesty mechanism. Deprecated software should not be presented as current, preferred, supported beyond recorded limits, deployment-ready, procurement-ready, financeable, insurable, publicly approved, consented, or executable. Deprecation helps users move responsibly toward successor objects without erasing history.

### 9.3.16 Archive

Archive is the repository and release governance process for preserving software objects, releases, branches, documentation, issues, pull requests, vulnerability notices, correction records, deprecation notices, withdrawal notices, recall notices, dependency records, Registry records, Marketplace listings, Studio workflow records, Grid and TRL records, Nexus Universe records, National Portfolio references, and handoff package records as memory without current authority.

A software archive record should identify:

1. archived repository, release, feature, branch, or object;
2. prior lifecycle state;
3. archive reason;
4. archive date;
5. archive steward;
6. successor object where applicable;
7. support status;
8. security status;
9. license and dependency status;
10. data-use and AI-use restrictions;
11. access class;
12. use and citation restrictions;
13. affected Marketplace and Registry records;
14. affected Studio, Grid, Nexus Universe, National Portfolio, and handoff records;
15. non-current authority notice.

Archive may follow completion, supersession, deprecation, support expiry, security concern, license concern, withdrawal, recall, project closure, Nexus Universe cycle closure, handoff completion, non-continuation, or public-safe restriction. Archive should preserve what happened while preventing stale software from being treated as current.

Archived software is not supported, procurement-ready, financeable, insurable, publicly approved, consented, deployment-authorized, or executable by default. It may remain available for historical study, learning, audit, reproducibility, or correction memory under its archive rule.

The final Repository and Release Governance rule is: create repositories with purpose; select licenses with discipline; accept contributions with terms; assign maintainers with scope; govern conduct; review dependencies and security; document public-safely; classify releases; list only with status truth; register lifecycle state; classify support honestly; correct visibly; deprecate responsibly; archive memory without current authority.

## 9.4 Secure Software Controls

### 9.4.1 Code Review

Code review is the secure software control through which Nexus software objects are examined before release, listing, Registry status update, Studio use, Nexus Universe presentation, Grid or TRL routing, National Portfolio inclusion, or handoff-context transfer. Code review protects public-good software from defects, unsafe assumptions, hidden dependencies, insecure patterns, undocumented behavior, role overclaim, public-safe documentation failures, and unreviewed contribution risk.

Code review should apply to repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, adapters, command-line tools, notebooks, templates, infrastructure-as-code, test suites, and reference implementations. The level of review should correspond to the object’s sensitivity, access class, data-use label, AI-use label, public-safe status, support class, release class, and handoff proximity.

A Code Review Record should identify:

1. reviewed object, including repository, branch, pull request, release, module, notebook, service, API, dashboard, connector, adapter, template, infrastructure-as-code object, or reference implementation;
2. review scope, including functional correctness, readability, maintainability, security, dependency use, error handling, access control, logging, data handling, AI-use controls, public-safe outputs, and boundary notices;
3. reviewer class, including maintainer, peer reviewer, security reviewer, data reviewer, AI reviewer, public-safe reviewer, accessibility reviewer, National Node reviewer, Studio reviewer, or handoff reviewer;
4. review outcome, including accepted, accepted with conditions, returned for revision, restricted, suspended, withdrawn, recalled, archived, or non-continuing;
5. unresolved issues, including defects, risks, assumptions, limitations, missing tests, missing documentation, missing security controls, missing public-safe language, or required follow-up;
6. correction pathway, including issue creation, patching, release correction, Registry update, Marketplace update, Studio workflow correction, Grid or TRL update, handoff recipient notice, or archive treatment.

Code review is not certification. It does not create warranty, procurement approval, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority. It creates a bounded review record for software movement inside Nexus.

### 9.4.2 Test Coverage

Test coverage is the secure software control through which Nexus records what software behavior has been tested, what remains untested, and what assumptions must not be inferred from a passing test suite. Test coverage supports confidence, repeatability, maintenance, release classification, correction, Grid and TRL routing, Studio readiness, and handoff-context clarity.

Test coverage may include:

1. unit tests, for discrete functions, modules, validators, transformation logic, and utilities;
2. integration tests, for APIs, services, connectors, adapters, dashboards, data pipelines, Studio workflows, Registry interfaces, Marketplace interfaces, Grid tools, and handoff-package tools;
3. regression tests, to prevent corrected issues from recurring;
4. security tests, for authentication, authorization, input validation, secrets handling, dependency behavior, and access controls;
5. data-quality tests, for schema compliance, missingness, range checks, lineage, metadata, and transformation integrity;
6. AI workflow tests, for prompt behavior, output controls, human-review routing, hallucination risk, leakage risk, and tool-use restrictions;
7. accessibility tests, for user-facing dashboards, applications, documents, learning objects, and Studio interfaces;
8. public-safe output tests, for boundary language, warning avoidance, overclaim detection, and safe display.

A Test Coverage Record should identify what was tested, what was not tested, what data or synthetic data was used, what environment was used, what dependencies were present, what pass/fail conditions mean, what limitations apply, and what correction pathway exists.

Passing tests does not create certification, safety approval, procurement status, deployment authorization, financeability, insurability, public authority action, consent, or execution authority. Test coverage is evidence of defined behavior under defined conditions; it is not proof of all uses.

### 9.4.3 Dependency Scanning

Dependency scanning is the secure software control through which Nexus identifies, monitors, and assesses third-party packages, libraries, containers, services, APIs, models, data dependencies, infrastructure modules, build tools, and transitive dependencies used by software objects.

Dependency scanning should address:

1. known vulnerabilities, including severity, exploitability, affected versions, patches, mitigations, and unresolved exposure;
2. license compatibility, including open-source license obligations, copyleft conditions, commercial restrictions, non-commercial restrictions, attribution obligations, model-use limits, and data-use restrictions;
3. supply-chain risk, including abandoned packages, malicious packages, dependency confusion, compromised maintainers, typosquatting, unpinned versions, unverified sources, and opaque binaries;
4. runtime risk, including hosted service dependencies, external API dependencies, provider platform dependencies, model endpoint dependencies, and cloud-service dependencies;
5. public-good compatibility, including lock-in, sovereignty concerns, restricted reuse, handoff limitations, and conflicts with open technical baseline goals.

A Dependency Scan Record should identify dependency inventory, scan date, tool or method used, vulnerability findings, license findings, unresolved risks, accepted risks, required updates, replacement options, release implications, support implications, Registry implications, Marketplace implications, and correction or archive triggers.

Dependency scanning is not a security certification. It is a risk-discovery control. A clean scan does not guarantee security, legality, deployment readiness, procurement readiness, financeability, insurability, public authority approval, consent, or execution authority.

### 9.4.4 Secret Scanning

Secret scanning is the secure software control used to detect and prevent exposure of credentials, API keys, tokens, passwords, private keys, certificates, service account files, connection strings, database credentials, signing keys, encryption keys, cloud credentials, webhook secrets, and other sensitive secrets in repositories, notebooks, configuration files, logs, release artifacts, containers, documentation, issue threads, pull requests, and handoff packages.

Secret scanning should apply before public release, Marketplace listing, Registry status update, Nexus Universe presentation, Studio use, Grid or TRL routing, handoff-context transfer, and archive where archive exposure could create continuing risk.

A Secret Scan Record should identify:

1. scan scope, including repositories, branches, pull requests, issues, notebooks, release files, containers, logs, documentation, and handoff materials;
2. detected secret class, including key, token, password, certificate, credential file, connection string, or other sensitive material;
3. severity and exposure pathway;
4. remediation action, including revocation, rotation, removal, history rewrite where appropriate, access restriction, recipient notification, public repair where required, and incident escalation;
5. downstream impact, including affected services, APIs, data, Studio workflows, National Nodes, Nexus Universe outputs, Marketplace listings, Registry records, handoff recipients, and archive materials;
6. closure and correction record.

Secret exposure may require immediate suspension, recall, access restriction, incident response, handoff recipient notice, or archive sealing. Secret scanning is not optional where software may be public, shared, listed, demonstrated, or handed off.

A repository with no detected secrets is not certified secure. It has passed one defined control at one point in time.

### 9.4.5 SBOM Records

Software Bill of Materials Records or SBOM Records document the components, dependencies, packages, libraries, modules, containers, build tools, runtime dependencies, licenses, versions, suppliers, and known vulnerability relationships associated with a Nexus software object.

SBOM Records support dependency review, security review, license review, release classification, support classification, correction, vulnerability disclosure, Grid and TRL routing, Marketplace listing, Registry status truth, Studio readiness, Nexus Universe presentation, National Portfolio use, and handoff context.

An SBOM Record should identify:

1. software object and version;
2. component inventory, including direct and transitive dependencies;
3. version and source information;
4. license information;
5. known vulnerability references where available;
6. build and runtime environment relationship;
7. container or infrastructure relationship where applicable;
8. model, data, API, or service dependencies where applicable;
9. support and update status;
10. correction, supersession, withdrawal, recall, and archive pathway.

SBOM Records should be updated when dependencies change, releases occur, vulnerabilities are discovered, license conditions change, build environments change, containers are updated, handoff packages are prepared, or support status changes.

An SBOM is not a warranty and not a certification. It is a transparency record. It helps users and recipients understand software composition without implying that the software is safe, approved, procured, financeable, insurable, deployment-ready, or executable.

### 9.4.6 Vulnerability Disclosure

Vulnerability disclosure is the secure software control through which suspected or confirmed vulnerabilities in Nexus software objects may be reported, triaged, restricted, corrected, disclosed, recalled, or archived without unsafe exposure or reputational suppression.

A Vulnerability Disclosure pathway should identify:

1. reporting channel, including public, controlled, private, secure, or maintainer-only channels;
2. eligible reporters, including contributors, users, researchers, maintainers, National Nodes, Studio participants, providers, public authority learners, handoff recipients, or external security researchers where appropriate;
3. triage process, including severity classification, exploitability, affected versions, affected deployments or demonstrations, affected data, affected APIs, affected recipients, and affected public surfaces;
4. confidentiality controls, including embargo handling, reporter protection, no-retaliation principles where applicable, and public-safe disclosure timing;
5. remediation actions, including patching, release correction, dependency update, key rotation, access restriction, suspension, withdrawal, recall, Registry update, Marketplace update, Studio shutdown, Grid downgrade, handoff notice, and archive sealing;
6. disclosure record, including what may be disclosed publicly, what must remain restricted, and how users are notified;
7. closure and correction pathway.

Vulnerability disclosure should balance transparency and safety. Premature public detail may create harm; silent suppression may create reliance risk. Nexus should disclose enough to protect users and preserve trust while controlling exploit-sensitive details.

A vulnerability disclosure process is not security certification. It is a repair and trust mechanism.

### 9.4.7 Threat Modeling

Threat modeling is the secure software control through which Nexus identifies credible threats, misuse cases, attack paths, failure modes, data exposure risks, AI misuse risks, public-safe risks, role-overclaim risks, operational risks, and handoff risks before software is released, demonstrated, listed, registered, used in Studio, routed through Grid or TRL, presented at Nexus Universe, or included in a handoff package.

Threat modeling should consider:

1. assets, including data, credentials, models, APIs, dashboards, repositories, infrastructure, metadata, public-safe summaries, protected knowledge, and handoff packages;
2. actors, including users, contributors, maintainers, providers, sponsors, public authority learners, capital readers, insurers, donors, communities, malicious actors, insiders, compromised accounts, automated agents, and downstream recipients;
3. attack paths, including credential theft, dependency compromise, prompt injection, data leakage, API misuse, privilege escalation, insecure configuration, supply-chain compromise, geospatial exposure, dashboard misuse, and handoff misuse;
4. misuse cases, including public authority overclaim, procurement overclaim, finance or insurance overclaim, provider validation overclaim, sponsor influence, community consent overclaim, AI automation beyond scope, and deployment by implication;
5. controls, including access control, least privilege, logging, secret management, secure defaults, public-safe language, review gates, data-use restrictions, AI-use restrictions, output review, correction, suspension, recall, and archive.

A Threat Model Record should identify scope, assumptions, threats, mitigations, residual risks, review status, release implications, support implications, and correction triggers.

Threat modeling does not eliminate risk. It makes risk visible before the object moves. It supports safer release without creating certification, warranty, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority.

### 9.4.8 Secure Defaults

Secure defaults are the design controls that cause Nexus software to start in the safest reasonable configuration unless a competent actor deliberately changes settings under recorded responsibility. Secure defaults reduce the risk that public-good software, examples, templates, dashboards, APIs, notebooks, services, connectors, Studio workflows, or handoff packages are used unsafely because insecure options were easy, hidden, or undocumented.

Secure defaults should include:

1. least privilege access;
2. closed or controlled access by default where sensitivity is uncertain;
3. no secrets in code or examples;
4. no public exposure of restricted data;
5. no write-back to external systems unless explicitly enabled and authorized;
6. no autonomous publication without public-safe review;
7. no autonomous handoff without Handoff Record and recipient responsibility;
8. no AI training on restricted inputs unless expressly permitted;
9. no logging of sensitive data unless necessary, lawful, protected, and recorded;
10. safe error messages that do not expose secrets, personal data, system internals, protected knowledge, or sensitive infrastructure details;
11. secure configuration examples;
12. safe sample data, preferably synthetic or public-safe where possible;
13. clear warnings for unsafe or experimental modes.

Secure defaults should be reviewed as part of code review, security review, documentation review, Studio readiness review, Grid or TRL routing, Marketplace listing, Registry status, and handoff packaging.

Secure defaults do not certify software as secure. They reduce unsafe use and make the default path less dangerous. Any downstream actor changing defaults assumes responsibility for independent review, safeguards, operations, and lawful use.

### 9.4.9 Accessibility Testing

Accessibility testing is the secure and inclusive software control through which Nexus verifies whether user-facing software, dashboards, applications, documentation, notebooks, learning tools, Campaign tools, Marketplace listings, Registry views, Studio interfaces, Grid tools, Reports interfaces, and Nexus Universe systems can be used by the intended audience, including persons with disabilities and users with different technical, linguistic, bandwidth, device, or literacy conditions.

Accessibility testing may include:

1. screen-reader compatibility;
2. keyboard navigation;
3. captions and transcripts;
4. alt text for images and charts;
5. contrast and visual readability;
6. semantic document structure;
7. form labels and error messages;
8. plain-language support;
9. mobile and low-bandwidth access;
10. multilingual or localization support;
11. accessibility for public authority learners, community participants, youth participants where appropriate, and non-technical users;
12. dashboard and visualization interpretation safeguards.

An Accessibility Test Record should identify tested object, audience, test method, findings, limitations, unresolved barriers, corrective actions, public-safe implications, release implications, and archive treatment.

Accessibility testing is part of public-good integrity. A tool that cannot be accessed by its intended users is not fit for its full public-good purpose. Accessibility testing does not create certification by default, but it provides evidence for release classification, support classification, public-safe status, Academy readiness, Campaign readiness, Marketplace listing, and Nexus Universe readiness.

### 9.4.10 Documentation Review

Documentation review is the secure software control through which repository documentation, README files, installation instructions, API docs, SDK docs, dashboard descriptions, notebook explanations, templates, release notes, security policies, contribution guides, public-safe notices, Marketplace descriptions, Registry notes, Grid notes, Studio notes, Nexus Universe materials, and handoff instructions are reviewed for accuracy, completeness, safety, accessibility, and boundary discipline.

Documentation review should examine whether documentation:

1. accurately describes purpose and scope;
2. identifies intended and prohibited uses;
3. explains installation and runtime requirements;
4. discloses dependencies and support status;
5. states data-use and AI-use labels;
6. states review status and limitations;
7. includes security guidance and vulnerability disclosure;
8. includes accessibility guidance where relevant;
9. includes public-safe language;
10. includes no-certification, no-warranty, no-procurement, no-finance, no-public-authority, no-consent, no-deployment, no-execution, no-provider-validation, and no-sponsor-control notices where relevant;
11. avoids promotional overclaim;
12. identifies correction and archive pathways.

A Documentation Review Record should identify reviewer class, scope, findings, required changes, unresolved issues, release implications, Marketplace implications, Registry implications, handoff implications, and correction pathway.

Documentation can create risk even when code is sound. Misleading documentation may cause deployment overclaim, public authority confusion, procurement confusion, finance or insurance overclaim, provider validation, sponsor control, unsafe data use, or consent overclaim. Documentation review is therefore a security, public-safe, and governance control.

### 9.4.11 Reproducibility Review

Reproducibility review is the secure software control through which Nexus examines whether software outputs, notebook results, dashboard calculations, data transformations, model evaluations, DRI indicators, GRIx mappings, Studio simulations, public-safe summaries, Grid inputs, Reports figures, or handoff package outputs can be reproduced, rerun, verified, or explained under recorded conditions.

Reproducibility review should identify:

1. software version;
2. repository state or commit reference;
3. runtime environment;
4. dependency versions;
5. data version or synthetic data substitute;
6. model version where applicable;
7. configuration parameters;
8. random seeds where relevant;
9. execution notes;
10. input and output records;
11. known nondeterminism;
12. access restrictions that limit reproducibility;
13. public-safe transformation steps;
14. review and correction pathway.

A Reproducibility Review Record should state whether reproduction is full, partial, controlled, restricted, secure-room-only, data-room-only, clean-room-only, compute-to-data-only, not possible due to rights or sensitivity, or not attempted. It should also identify what claims can and cannot be supported by the review.

Reproducibility is not universal validity. Reproducing an output does not certify the method, prove the assumptions, approve the data, authorize deployment, or create public authority action. It shows that a defined output can be obtained under defined conditions. That is valuable evidence, not authority.

### 9.4.12 Release Notes

Release notes are the secure software control through which changes to a software object are communicated at release. Release notes preserve version meaning, user awareness, correction history, dependency changes, security implications, support status, public-safe status, and no-conversion boundaries.

Release notes should identify:

1. release version and date;
2. release class;
3. object class and repository;
4. steward and maintainer;
5. major changes;
6. bug fixes;
7. security fixes;
8. dependency changes;
9. data-use or AI-use changes;
10. public-safe documentation changes;
11. breaking changes;
12. known limitations;
13. support status;
14. upgrade or migration guidance;
15. deprecation, withdrawal, recall, supersession, archive, or non-continuation notes where applicable;
16. Marketplace and Registry implications;
17. Studio, Grid, TRL, National Portfolio, Nexus Universe, or handoff implications where applicable;
18. boundary notices, including no-warranty, no-certification, no-procurement, no-deployment, and no-execution.

Release notes should be written for both technical and governance understanding. A user should understand not only what changed in the software, but also what changed in the object’s status, support, security, public-safe release, and permitted use.

Release notes do not create warranty or approval. They communicate release state. Their discipline helps prevent stale versions, misunderstood updates, hidden breaking changes, uncommunicated security fixes, and unsafe reliance.

The final Secure Software Controls rule is: secure public-good software requires code review, testing, dependency scanning, secret scanning, SBOM records, vulnerability disclosure, threat modeling, secure defaults, accessibility testing, documentation review, reproducibility review, and release notes; each control creates evidence for safer routing, release, support, correction, and handoff, but none creates certification, warranty, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 9.5 Software Boundaries

### 9.5.1 Software Release Is Not Warranty

A software release is not warranty. A Nexus software release may be public, controlled, restricted, Studio-ready, Nexus-Universe-ready, Marketplace-discoverable, Registry-recorded, Grid or TRL-classified, supported within scope, reviewed within scope, or included in handoff context. None of those conditions creates a warranty of accuracy, completeness, security, performance, availability, fitness for purpose, non-infringement, merchantability, operational continuity, public authority acceptance, procurement eligibility, financeability, insurability, deployment suitability, or lawful implementation.

A software release should carry clear no-warranty language in the repository, release notes, documentation, Marketplace listing, Registry record, Studio workflow notes, Grid or TRL record, Nexus Universe materials, National Portfolio reference, and handoff package where applicable. The notice should explain that users and recipients remain responsible for their own legal, technical, security, operational, data, AI, procurement, finance, insurance, public authority, consent, deployment, and implementation review before relying on the software outside the recorded Nexus public-good context.

A software release may still be valuable without warranty. It may support learning, review, reproducibility, public-good reuse, Studio demonstration, National Portfolio preparation, Nexus Universe production, Marketplace discovery, Registry status truth, Grid maturity input, and lawful handoff context. Its value arises from transparency, documentation, versioning, review records, support classification, correction pathways, and archive discipline—not from implied guarantees.

Any warranty, indemnity, service-level commitment, reliance permission, production assurance, maintenance obligation, or operational guarantee must be created separately by a competent actor through a lawful instrument. It must not be inferred from Nexus release status.

### 9.5.2 Reference Implementation Is Not Production Approval

A reference implementation is not production approval. A Nexus reference implementation demonstrates one documented way to implement a method, schema, API, workflow, dashboard, data transformation, DRI process, GRIx mapping, DICE pattern, Observatory connector, Studio workflow, Registry function, Marketplace function, Grid or TRL process, Academy workflow, Campaign tool, National Portfolio tool, Nexus Universe tool, or handoff-package pattern. It does not approve production use by default.

A reference implementation should be understood as a public-good learning, demonstration, review, and interoperability object. It may show how a concept can be implemented in controlled form. It may help contributors understand architecture. It may help reviewers inspect assumptions. It may help National Nodes localize a workflow. It may help lawful recipients understand handoff context. It may help developers build compatible systems. None of those functions authorizes live operation.

Production approval requires a separate competent actor to conduct independent technical review, security review, data-rights review, AI-use review, privacy review, accessibility review, operational readiness review, legal review, procurement where required, finance where required, insurance where required, public authority approval where required, consent where required, support and maintenance planning, incident response planning, and liability allocation.

A reference implementation must not be described as “approved,” “certified,” “deployment-ready,” “procurement-ready,” “production-grade,” or “authorized” unless that status has been separately established, scoped, and recorded. Nexus may provide a reference. It does not approve production by implication.

### 9.5.3 Open-Source Availability Is Not Deployment Authorization

Open-source availability is not deployment authorization. Making software available under an open-source license, public repository, public-good baseline, reference implementation, public-safe release, Marketplace listing, Nexus Universe demonstration, Academy module, or handoff context does not authorize deployment, production use, field use, operational use, public authority use, enterprise implementation, infrastructure integration, community implementation, or system operation.

Open-source availability may grant certain rights to inspect, copy, modify, or distribute software under the applicable license. It does not grant data rights, AI-training rights, model-use rights, public authority approval, procurement approval, finance approval, insurance approval, export-control clearance, cybersecurity clearance, protected knowledge permission, community consent, Indigenous consent where applicable, operational authority, deployment authority, or execution authority.

An open-source software object should therefore carry:

1. license terms, explaining what the license permits and requires;
2. data-use and AI-use labels, explaining what the software may process and what it must not process;
3. security and dependency notes, explaining known risks and required review;
4. support classification, explaining whether the object is maintained, conditionally supported, unsupported, deprecated, suspended, withdrawn, recalled, archive-only, or non-continuing;
5. deployment boundary notices, explaining that any downstream deployment requires separate competent review and authorization.

Open-source release supports transparency and public-good reuse. It does not convert Nexus into an operator, approver, certifier, procurer, insurer, financier, public authority, consent holder, or executing actor.

### 9.5.4 Code Review Is Not Security Certification

Code review is not security certification. A Nexus software object may pass code review, peer review, maintainer review, security review, dependency review, secret scanning, SBOM review, threat modeling, test coverage review, documentation review, reproducibility review, or release review. These reviews improve confidence within defined scope, but they do not certify that the software is secure for all uses, environments, actors, jurisdictions, datasets, integrations, deployments, or downstream operational contexts.

Code review may identify defects, improve maintainability, detect insecure patterns, confirm documentation, require tests, identify dependency risks, strengthen public-safe notices, and support release classification. It cannot eliminate all vulnerabilities, supply-chain risks, configuration risks, operational risks, insider risks, misuse risks, data leakage risks, AI workflow risks, public authority overclaim risks, finance or insurance overclaim risks, or downstream deployment risks.

A Code Review Record or Security Review Record should state:

1. what was reviewed;
2. what was not reviewed;
3. what tools or methods were used;
4. what findings were resolved;
5. what risks remain;
6. what release class is supported;
7. what support class applies;
8. what correction, suspension, withdrawal, recall, or archive pathway applies.

Security certification, where required, must be performed by a competent certifying authority or responsible actor under an applicable standard, legal framework, procurement requirement, public authority requirement, contractual framework, or operational assurance process. Nexus review may support that process as evidence; it does not replace it.

### 9.5.5 Marketplace Listing Is Not Procurement Recommendation

A Marketplace listing is not procurement recommendation. A Nexus software object may appear in Nexus Marketplace because it is discoverable, public-safe enough for listing, Registry-linked, documented, support-classified, contribution-ready, learning-ready, Studio-ready, Nexus-Universe-linked, National-Portfolio-linked, or handoff-context-relevant. That listing does not mean Nexus recommends that any actor procure, purchase, contract for, adopt, deploy, integrate, finance, insure, certify, or rely on the software.

Marketplace listing should make software easier to find and understand. It should show object identity, version, steward, license class, access class, release class, support class, review status, security review status where relevant, dependency status where relevant, data-use and AI-use labels, public-safe documentation, Registry status, Grid or TRL relationship where applicable, Studio relationship where applicable, Nexus Universe relationship where applicable, handoff-context relationship where applicable, and correction or delisting pathway.

A Marketplace-listed software object must not be represented as:

1. selected by Nexus for procurement;
2. approved by a public authority;
3. certified by the Registry;
4. validated by a provider contribution;
5. endorsed by sponsor support;
6. financeable or insurable by Grid or TRL status;
7. deployment-ready because it is discoverable;
8. operationally safe because it is public;
9. recommended for purchase because it is visible;
10. authorized for implementation because it is listed.

Procurement belongs to separate competent procuring actors under their own procurement rules, diligence, conflicts process, budget authority, contracting authority, security review, data review, legal review, public authority approval where required, and accountability framework. The Marketplace provides discovery, not selection.

### 9.5.6 Provider Contribution Is Not Provider Validation

A provider contribution is not provider validation. A provider may contribute code, APIs, infrastructure, data tools, cloud credits, compute, documentation, expertise, review support, test environments, dashboards, connectors, SDKs, Studio components, Nexus Universe support, Academy materials, Foundry support, or handoff-context materials. Such contribution does not certify, validate, endorse, approve, rank, prefer, procure, select, recommend, or authorize the provider by default.

Provider contribution should be recorded through Provider Contribution Records, object metadata, repository contribution history, Support Records, Marketplace notes, Registry notes, release notes, and correction pathways where material. The record should distinguish what the provider contributed from what Nexus reviewed, accepted, modified, rejected, restricted, corrected, deprecated, withdrew, recalled, or archived.

A provider-contributed software object should carry clear notices that:

1. provider contribution is not provider certification;
2. provider support is not procurement preference;
3. provider documentation is not Nexus endorsement;
4. provider code is not automatically accepted without review;
5. provider involvement does not control evidence, methods, release class, Registry status, Marketplace listing, Grid or TRL status, public-safe documentation, correction, withdrawal, recall, archive, or handoff status;
6. provider presence in Nexus Universe or Studio does not authorize deployment;
7. provider inclusion in handoff context is not contract award.

Nexus may accept valuable provider expertise while preserving public-good neutrality. Any provider selection, procurement, contract, certification, deployment, finance, insurance, public authority approval, or operational role must arise separately through competent lawful processes.

The final Software Boundaries rule is: software release is not warranty; reference implementation is not production approval; open-source availability is not deployment authorization; code review is not security certification; Marketplace listing is not procurement recommendation; provider contribution is not provider validation. Software may inform, teach, demonstrate, support, and prepare context, but it does not certify, warrant, procure, finance, insure, approve, consent, deploy, or execute by implication.

<br>


---

# 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/standardization/nexus-ecosystem/ii.-structure/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.