ARTICLE XI. ASSETS

Section 309. Public-Good Technical Asset Purpose

309.1 Public-Good Technical Asset Purpose.

309.1.1 Public-Good Technical Assets are mission-aligned technical materials, tools, reference structures, software artifacts, evidence interfaces, schemas, baselines, documentation, repositories, evaluation instruments, and related technical outputs developed, maintained, received, contributed to, adopted, released, restricted, corrected, superseded, withdrawn, or archived by the Corporation in furtherance of its public-benefit purposes.

309.1.2 Public-Good Technical Assets shall support the Corporation’s non-executing role as a public-benefit evidence, methods, observability, ontology, public-good R&D, public-good software, open technical baseline, verifiable compute, verifiable intelligence, public authority learning, safeguards, and public-safe publication institution.

309.1.3 Public-Good Technical Assets may include software, repositories, open technical baselines, schemas, APIs, SDKs, dashboards, maps, data tools, reference architectures, model cards, system cards, dataset cards, benchmark cards, evaluation harnesses, test harnesses, Gold Vectors, negative tests, benchmark libraries, ontologies, controlled vocabularies, data dictionaries, documentation, proof-receipt formats, evidence templates, public-safe publication templates, and related assets.

309.1.4 Public-Good Technical Assets shall be governed to preserve public trust, public-benefit use, open technical memory, secure release, data / AI / cyber / privacy controls, protected knowledge safeguards, public authority boundary discipline, finance-boundary discipline, certification-boundary discipline, recognition-boundary discipline, procurement neutrality, provider neutrality, correctionability, and role separation across GCRI US, GCRI Canada, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards, Nexus Observatory, Nexus Rails, Nexus Grid, Nexus Academy, consortiums, national companies, Project SPVs, providers, sponsors, hosts, public authorities, universities, laboratories, communities, and other participants.

309.2 Software as Public-Good Infrastructure.

309.2.1 Software developed, maintained, released, or supported by the Corporation may serve as public-good infrastructure when it provides reusable technical capability for research, evidence integrity, observability, ontology, public-safe publication, public authority learning, data governance, AI governance, cybersecurity, verifiable compute, verifiable intelligence, technical baselines, community safeguards, or Nexus-compatible interoperability.

309.2.2 Public-good software shall be stewarded as infrastructure of trust, not merely code. Its governance shall include purpose definition, scope control, maintainer assignment, repository governance, secure development, documentation, licensing, dependency management, vulnerability management, release controls, limitation language, public-safe guidance, correction pathways, and retirement rules.

309.2.3 Public-good software shall not be represented as enterprise deployment, operational command, managed service, regulated service, public authority system, public warning system, certification system, recognition system, finance-readiness system, procurement system, provider ranking system, investment system, or emergency response system.

309.3 Open Technical Baselines as Public-Good Reference Materials.

309.3.1 Open Technical Baselines are public-good reference materials that describe non-executing technical structures, recommended fields, methods, schemas, interoperability patterns, governance patterns, documentation patterns, evidence formats, data governance expectations, AI governance expectations, cybersecurity expectations, observability patterns, public authority learning supports, and Nexus-compatible technical concepts.

309.3.2 Open Technical Baselines may guide shared understanding, reduce fragmentation, support public-good interoperability, preserve technical memory, and improve consistency without creating binding legal mandates, certification, procurement requirements, public authority standards, finance-readiness determinations, provider qualifications, or ratings.

309.3.3 Open Technical Baselines shall be versioned, scoped, limitation-aware, public-safe reviewed, provider-neutral, correctionable, and distinguishable from formal standards, legal compliance approvals, certifications, public authority rules, procurement specifications, and enterprise requirements unless separately and lawfully adopted by a competent body outside the Corporation’s non-executing role.

309.4 Schemas as Interoperability Instruments.

309.4.1 Schemas may be developed, adopted, maintained, released, restricted, corrected, or archived by the Corporation as interoperability instruments for evidence records, methods records, data records, observability records, public authority capacity records, correction records, proof receipts, technical baselines, public-good software, controlled-room records, AI inference records, compute workload records, dashboards, maps, Docket inputs, Grid inputs, GRF-facing inputs, GRA-facing inputs, and other Nexus-compatible materials.

309.4.2 Schemas shall define structure, fields, permissible values, metadata, versioning, validation rules, classification rules, access classes, data rights fields, public-safe status fields, correction fields, and boundary limitation fields where appropriate.

309.4.3 Schema alignment shall not imply certification, recognition, finance-readiness, procurement approval, public authority approval, provider qualification, software approval, legal compliance approval, or execution authority.

309.5 APIs and SDKs as Technical Interface Instruments.

309.5.1 APIs and SDKs may be developed, maintained, documented, released, restricted, or deprecated by the Corporation to support controlled technical interfaces among public-good software, evidence systems, observability systems, dashboards, maps, data tools, repositories, validation workflows, proof-receipt systems, verifiable compute workflows, public authority learning tools, and Nexus-compatible technical assets.

309.5.2 APIs and SDKs shall be governed through secure development, access control, authentication, authorization, versioning, rate limits where appropriate, logging where appropriate, public-safe documentation, data classification, privacy controls, AI-use controls, cyber controls, dependency management, deprecation notices, and correction paths.

309.5.3 API or SDK availability shall not create a right of access, production entitlement, public authority integration, procurement approval, provider preference, certification, recognition, finance-readiness, operational reliance, or service-level guarantee unless separately and lawfully agreed by competent authority.

309.6 Dashboards and Data Tools as Public-Safe Evidence Interfaces.

309.6.1 Dashboards, maps, analytics tools, visualization tools, query tools, evidence interfaces, and related data tools may support public-safe evidence access, observability, public authority learning, technical baseline interpretation, community safeguards, and public-benefit research.

309.6.2 Such tools shall be designed and reviewed for evidence support, source lineage, data quality, public-safe status, privacy, accessibility, civil rights, cyber sensitivity, infrastructure sensitivity, public authority boundary discipline, protected knowledge safeguards, finance-boundary discipline, certification-boundary discipline, recognition-boundary discipline, procurement neutrality, provider neutrality, and correctionability.

309.6.3 No dashboard, map, data tool, indicator, score, visualization, filter, query result, alert-like display, degraded-mode note, hotspot view, or resilience indicator shall constitute or be represented as public warning, emergency command, public authority decision, finance-readiness, certification, procurement approval, recognition, rating, provider preference, investment suitability, insurance-readiness, bankability, public finance approval, or enterprise execution.

309.7 Reference Architectures as Non-Executing Design Support.

309.7.1 Reference Architectures may provide non-executing design support for evidence systems, observability environments, data governance structures, AI governance structures, cyber controls, controlled rooms, public-good software, technical baselines, public authority learning environments, verifiable compute workflows, verifiable intelligence workflows, Nexus-compatible national or regional public-good architectures, and related technical systems.

309.7.2 Reference Architectures shall identify purpose, scope, assumptions, intended users, dependencies, limitations, security considerations, privacy considerations, public authority considerations, protected knowledge considerations, data / AI / cyber considerations, and public-safe use guidance.

309.7.3 Reference Architectures shall not be represented as engineering certification, professional design approval, procurement specification, public authority approval, construction instruction, operational command, enterprise deployment approval, security guarantee, finance-readiness, recognition, rating, or legal compliance approval.

309.8 Model Cards, System Cards, Dataset Cards, Benchmark Cards, and Evaluation Harnesses as Accountability Instruments.

309.8.1 Model Cards, System Cards, Dataset Cards, Benchmark Cards, and Evaluation Harnesses shall be treated as accountability instruments that document purpose, scope, data sources, evaluation methods, limitations, bias risks, safety risks, public-safe status, known issues, permitted uses, prohibited uses, version, custodian, and correction path.

309.8.2 Such instruments shall support transparency, reviewability, reproducibility where appropriate, public-safe interpretation, AI governance, public authority learning, evidence integrity, and correctionability.

309.8.3 Such instruments shall not constitute certification, accreditation, safety approval, legal compliance approval, procurement approval, finance-readiness, recognition, rating, public authority approval, provider endorsement, or guarantee.

309.9 Test Harnesses, Gold Vectors, Negative Tests, and Benchmark Libraries as Methods Support.

309.9.1 Test Harnesses, Gold Vectors, negative tests, evaluation sets, benchmark libraries, reference cases, adversarial cases, calibration cases, regression tests, and validation cases may be developed, maintained, released, restricted, or archived as methods-support assets.

309.9.2 Such assets shall be versioned, documented, access-controlled where necessary, protected against leakage or gaming, reviewed for bias and representativeness where appropriate, secured where sensitive, and linked to method records, evaluation records, limitation records, and correction paths.

309.9.3 Benchmark or test performance shall not be represented as ranking, certification, provider preference, procurement recommendation, finance-readiness, recognition, public authority approval, legal compliance approval, safety guarantee, or public warning.

309.10 Ontologies, Controlled Vocabularies, and Data Dictionaries as Semantic Infrastructure.

309.10.1 Ontologies, controlled vocabularies, taxonomies, data dictionaries, schemas, semantic mappings, and related semantic assets shall be treated as public-good semantic infrastructure for consistent meaning, interoperability, evidence classification, data governance, AI governance, public-safe publication, public authority capacity classification, boundary discipline, and Nexus-compatible technical memory.

309.10.2 Semantic infrastructure shall distinguish evidence from opinion, observability from warning, technical baseline from certification, compatibility from approval, public authority learning from public authority action, GRF-facing input from GRF recognition, GRA-facing input from GRA finance-readiness, and public-good reference from enterprise execution.

309.10.3 Semantic infrastructure shall be reviewed for semantic drift, misleading public use, sponsor or provider capture, public authority overclaim, finance overclaim, certification overclaim, recognition overclaim, procurement overclaim, and correction needs.

309.11 Repositories as Technical Memory.

309.11.1 Repositories shall serve as technical memory for public-good software, technical baselines, schemas, ontologies, controlled vocabularies, data dictionaries, methods, documentation, evaluation assets, issue records, release records, correction records, vulnerability records, license records, provenance records, and archival records.

309.11.2 Repository governance shall protect access, integrity, version history, issue history, release history, provenance, license discipline, contributor records, security, secrets, keys, tokens, dependency history, SBOM records where appropriate, artifact signing records where appropriate, and correctionability.

309.11.3 Repositories shall not be used as uncontrolled dumping grounds for sensitive data, public authority data, protected knowledge, credentials, unreviewed AI outputs, unsupported claims, or public-safe publication materials outside approved release controls.

309.12 Secure Release as Public Trust Control.

309.12.1 Secure release shall be treated as a public trust control for Public-Good Technical Assets.

309.12.2 Secure release shall include review of security, privacy, data rights, AI-use restrictions, cyber sensitivity, infrastructure sensitivity, controlled technology, export-control, sanctions, licenses, dependencies, vulnerabilities, public-safe language, documentation, limitation statements, provenance, release authority, correction path, and rollback or withdrawal plan where appropriate.

309.12.3 No Public-Good Technical Asset shall be released in a manner that exposes sensitive data, protected knowledge, credentials, vulnerabilities, unsupported public claims, misleading authority, provider preference, sponsor control, or boundary-defective language.

309.13 Public-Good Technical Assets as Distinct From Certification.

309.13.1 Public-Good Technical Assets shall not constitute certification, accreditation, conformance approval, safety approval, legal compliance approval, professional approval, cybersecurity compliance approval, AI safety approval, privacy compliance approval, provider qualification, procurement qualification, or warranty.

309.13.2 Use, adoption, implementation, contribution, alignment, or compatibility with a Public-Good Technical Asset shall not be described as certified by the Corporation unless a separate competent certification authority lawfully issues such certification and the Corporation accurately references that separate status.

309.14 Public-Good Technical Assets as Distinct From Procurement Approval.

309.14.1 Public-Good Technical Assets shall not constitute procurement approval, procurement mandate, vendor selection criterion, preferred provider list, public contract requirement, grant requirement, public-private partnership requirement, product approval, or purchasing recommendation.

309.14.2 Public authorities, providers, sponsors, funders, national companies, Project SPVs, enterprise actors, and other persons shall not represent use of or alignment with a Public-Good Technical Asset as procurement approval by the Corporation.

309.15 Public-Good Technical Assets as Distinct From Provider Preference.

309.15.1 Public-Good Technical Assets shall be provider-neutral unless a documented public-benefit reason requires otherwise and the limitation is disclosed.

309.15.2 Provider contribution, sponsorship, hosting, code contribution, data contribution, technical assistance, cloud credits, equipment access, or participation shall not create provider preference, endorsement, ranking, market advantage, technical approval, procurement advantage, or public authority approval.

309.15.3 Provider influence shall be disclosed, restricted, ring-fenced, refused, or corrected where necessary to preserve neutrality and public trust.

309.16 Public-Good Technical Assets as Distinct From Public Authority Adoption.

309.16.1 Public-Good Technical Assets shall not constitute public authority adoption, regulation, guidance, official standard, public warning, emergency command, procurement requirement, grant requirement, public finance approval, sovereign decision, or public-private partnership unless a competent public authority separately and lawfully adopts or issues such status through its own process.

309.16.2 Public authority participation in development, review, use, comment, learning, controlled-room access, pilots, or publication shall be capacity-classified and shall not be represented as official adoption absent competent public authority record.

309.17 Public-Good Technical Assets as Distinct From Finance-Readiness or Rating.

309.17.1 Public-Good Technical Assets shall not constitute finance-readiness, investment suitability, bankability, insurance-readiness, underwriting approval, creditworthiness, rating, securities recommendation, capital placement, public finance approval, guarantee, or GRA action.

309.17.2 Public-Good Technical Assets may support evidence quality, data structure, methods discipline, technical understanding, or GRA-facing inputs only within the Corporation’s non-finance, non-executing, evidence-support role and only with limitation language sufficient to prevent capital-market overclaim.

309.18 Public-Good Technical Asset Records.

309.18.1 The Corporation shall maintain Public-Good Technical Asset Records, including purpose records, software records, open technical baseline records, schema records, API and SDK records, dashboard and data tool records, reference architecture records, model card records, system card records, dataset card records, benchmark card records, evaluation harness records, test harness records, Gold Vector records, negative test records, benchmark library records, ontology records, controlled vocabulary records, data dictionary records, repository records, secure release records, boundary records, provider-neutrality records, corrections, supersessions, withdrawals, deprecations, retirements, and archive records.

---

Section 310. Technical Asset Register

310.1 Technical Asset Register Requirement.

310.1.1 The Corporation shall maintain a Technical Asset Register for material Public-Good Technical Assets developed, maintained, adopted, released, restricted, received, contributed to, corrected, superseded, deprecated, retired, or archived by the Corporation.

310.1.2 The Technical Asset Register shall provide authoritative institutional memory concerning each material asset’s identity, class, owner, steward, maintainer, repository location, version, license, release status, public-safe status, confidentiality status, security status, dependency status, vulnerability status, export-control or controlled technology status, data / AI / cyber / privacy status, community safeguards and protected knowledge status, Nexus interface status, correction path, and deprecation or retirement status.

310.1.3 The Technical Asset Register shall support secure release, public-safe publication, repository governance, license discipline, dependency management, vulnerability management, correctionability, continuity, auditability, and prevention of unsupported public claims.

310.2 Register Custodian.

310.2.1 The Board, an authorized officer, or a competent technical governance body shall designate a Register Custodian for the Technical Asset Register.

310.2.2 The Register Custodian shall maintain register integrity, ensure updates, manage access, preserve history, record corrections, identify stale entries, and coordinate with software maintainers, data stewards, AI governance leads, cybersecurity leads, publication reviewers, and records custodians.

310.2.3 Register custody shall not confer authority to approve public release, certify assets, grant procurement approval, recognize providers, determine finance-readiness, or create public authority adoption.

310.3 Asset Identifier.

310.3.1 Each material asset shall have a unique Asset Identifier sufficient to distinguish it from other assets, versions, forks, variants, repositories, datasets, models, schemas, baselines, dashboards, or documentation packages.

310.3.2 Asset Identifiers shall be used in release notes, correction notices, dependency records, repository records, vulnerability records, public-safe publication records, and archive records where appropriate.

310.4 Asset Name.

310.4.1 Each material asset shall have an Asset Name approved or recorded by competent authority.

310.4.2 Asset Names shall be clear, non-misleading, and shall not imply certification, recognition, finance-readiness, public authority approval, procurement approval, public warning, emergency command, provider endorsement, or legal compliance approval unless separately supported by competent authority and accurately described.

310.5 Asset Class.

310.5.1 Each material asset shall be assigned an Asset Class.

310.5.2 Asset Classes may include software, schema, API, SDK, dashboard, map, data tool, reference architecture, open technical baseline, model card, system card, dataset card, benchmark card, evaluation harness, test harness, Gold Vector, negative test, benchmark library, ontology, controlled vocabulary, data dictionary, proof-receipt format, documentation package, repository, or other approved class.

310.5.3 Asset Class shall inform release controls, security controls, license review, data review, AI review, public-safe review, dependency review, correction path, and retirement rules.

310.6 Asset Owner.

310.6.1 Each material asset shall have an Asset Owner responsible for institutional purpose, scope, public-benefit alignment, continuing need, and authority for material lifecycle decisions within delegated authority.

310.6.2 Asset Owner status shall not create personal ownership, private control, sponsor control, provider control, public authority authority, certification authority, recognition authority, finance-readiness authority, procurement authority, or publication authority beyond recorded delegation.

310.7 Asset Steward.

310.7.1 Each material asset may have an Asset Steward responsible for day-to-day stewardship, documentation, public-safe framing, user guidance, issue triage, change coordination, correction coordination, and coordination with maintainers and custodians.

310.7.2 Asset Steward responsibilities shall be recorded where material and shall remain subject to governance controls, secure development controls, public-safe publication controls, and correction rules.

310.8 Asset Maintainer.

310.8.1 Each material technical asset that requires ongoing maintenance shall have one or more Asset Maintainers assigned by record.

310.8.2 Asset Maintainers may manage code, documentation, issues, pull requests, dependencies, releases, vulnerability fixes, baseline updates, schema updates, dashboard updates, and user guidance within approved scope.

310.8.3 Maintainers shall follow secure development, repository governance, license review, dependency review, vulnerability review, public-safe release, and correction requirements.

310.9 Repository Location.

310.9.1 The Technical Asset Register shall identify the repository, storage location, package registry, documentation site, controlled room, archive location, or other authoritative location for each material asset.

310.9.2 Repository location records shall distinguish public repositories, internal repositories, restricted repositories, controlled-room repositories, archived repositories, mirrors, forks, and deprecated locations.

310.9.3 Assets shall not be treated as authoritative merely because a copy exists outside the registered location.

310.10 Version.

310.10.1 Each material asset shall have a version identifier where versioning is necessary to preserve technical memory, dependency management, public-safe publication, interoperability, correction, or release control.

310.10.2 Version records shall identify effective date, release date where applicable, change rationale, compatibility, supersession status, migration guidance where appropriate, and affected downstream dependencies.

310.11 License.

310.11.1 Each material asset shall have a recorded license status.

310.11.2 License records shall identify open-source license, permissive license, copyleft license, documentation license, data license, proprietary restriction, internal-only status, third-party license dependencies, attribution requirements, redistribution rights, commercial-use restrictions, AI-use restrictions, and termination risks where applicable.

310.11.3 No asset shall be externally released without license review appropriate to its class and risk.

310.12 Release Status.

310.12.1 Each material asset shall have a Release Status.

310.12.2 Release Status may include concept, draft, prototype, experimental, internal, controlled, pilot, public-safe draft, public release candidate, public release, restricted release, deprecated, superseded, withdrawn, retired, archived, or prohibited.

310.12.3 Release Status shall be reflected in documentation and user guidance where necessary to prevent misuse or overreliance.

310.13 Public-Safe Status.

310.13.1 Each material asset shall have a Public-Safe Status where external use, publication, visualization, documentation, or public authority learning may occur.

310.13.2 Public-Safe Status shall reflect review for privacy, public authority restrictions, protected knowledge, cyber sensitivity, infrastructure sensitivity, finance-boundary risk, certification-boundary risk, recognition-boundary risk, procurement-neutrality risk, provider-neutrality risk, public warning implication, and emergency-command implication.

310.14 Confidentiality Status.

310.14.1 Each material asset shall have a Confidentiality Status identifying whether the asset is public, public-safe, internal, confidential, restricted, privileged, sealed, public authority-restricted, controlled-room-only, cyber-restricted, infrastructure-restricted, protected-knowledge-restricted, or otherwise limited.

310.14.2 Confidentiality Status shall determine repository access, documentation access, release eligibility, AI-use eligibility, transfer rules, and retention or deletion obligations.

310.15 Security Status.

310.15.1 Each material asset shall have a Security Status proportionate to its class and risk.

310.15.2 Security Status may identify whether security review is not required, pending, complete, limited, failed, conditionally approved, restricted, suspended, or requires remediation.

310.15.3 Assets with unresolved high-risk security concerns shall not be publicly released or used in high-reliance contexts unless competent authority records risk acceptance and mitigation.

310.16 Dependency Status.

310.16.1 Each material software, tool, dashboard, API, SDK, model, evaluation harness, or technical asset with dependencies shall have a Dependency Status.

310.16.2 Dependency Status shall identify known dependencies, critical dependencies, outdated dependencies, unsupported dependencies, vulnerable dependencies, license-sensitive dependencies, provider-dependent components, and required remediation.

310.17 Vulnerability Status.

310.17.1 Each material technical asset shall have a Vulnerability Status where security vulnerability risk is relevant.

310.17.2 Vulnerability Status may identify no known vulnerability, review pending, known low / moderate / high / critical vulnerability, mitigated vulnerability, accepted risk, patched, withdrawn, or restricted.

310.17.3 Vulnerability Status shall be updated after vulnerability review, incident response, dependency alerts, coordinated disclosure, release, patch, or withdrawal.

310.18 Export-Control or Controlled Technology Status.

310.18.1 Each material asset shall be reviewed where appropriate for export-control, sanctions, controlled technology, national security sensitivity, controlled encryption, controlled geospatial, cyber, AI, telecom, robotics, drone, semiconductor, advanced manufacturing, digital twin, or infrastructure sensitivity.

310.18.2 Export-Control or Controlled Technology Status shall determine access, release, transfer, publication, repository visibility, contributor eligibility where lawful and required, controlled-room requirements, and legal review.

310.19 Data / AI / Cyber / Privacy Status.

310.19.1 Each material asset shall have a Data / AI / Cyber / Privacy Status where the asset uses, processes, exposes, generates, documents, stores, transfers, or relies upon data, AI systems, cyber-sensitive materials, or privacy-relevant information.

310.19.2 The status shall identify whether data governance review, AI governance review, cybersecurity review, privacy review, model review, inference review, training restriction review, or incident review is required, pending, complete, restricted, or not applicable.

310.20 Community Safeguards and Protected Knowledge Status.

310.20.1 Each material asset shall be reviewed where appropriate for community safeguards, civil rights, accessibility, Tribal / Indigenous data, local knowledge, territorial knowledge, cultural knowledge, environmental knowledge, public-safe mapping, protected knowledge, and non-retaliation risk.

310.20.2 Community Safeguards and Protected Knowledge Status shall determine whether the asset may be published, mapped, translated, generalized, AI-processed, externally shared, or used in public authority learning materials.

310.21 Nexus Interface Status.

310.21.1 Each material asset shall identify whether and how it interfaces with Nexus Network, Nexus Observatory, Nexus Standards, Nexus Risk Management, Nexus Rails, Nexus Grid, Nexus Academy, Nexus Universe, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), consortiums, national companies, Project SPVs, public authorities, providers, sponsors, hosts, universities, laboratories, communities, or other Nexus participants.

310.21.2 Nexus Interface Status shall distinguish technical compatibility, evidence input, Docket input, Grid input, GRF-facing input, GRA-facing input, public authority learning support, public-good software support, and enterprise-stack interaction.

310.21.3 Nexus Interface Status shall not imply shared governance, agency, partnership, joint venture, shared treasury, public authority delegation, GRF recognition, GRA finance-readiness, certification, procurement approval, provider preference, or execution authority.

310.22 Correction Path.

310.22.1 Each material asset shall have a Correction Path identifying how errors, vulnerabilities, license issues, data issues, AI issues, public-safe issues, protected knowledge issues, boundary overclaims, documentation errors, dependency issues, and user reports are received, triaged, corrected, superseded, withdrawn, or retired.

310.22.2 Correction Paths shall identify custodian, review authority, issue channel, severity classification where applicable, release pathway, notice pathway, downstream dependency notification, and archive treatment.

310.23 Deprecation or Retirement Status.

310.23.1 Each material asset shall have a Deprecation or Retirement Status where it is no longer current, supported, safe, maintained, recommended, public-safe, compatible, or within mission scope.

310.23.2 Deprecation or retirement records shall identify reason, effective date, replacement asset if any, migration guidance where appropriate, affected dependencies, public-safe notice, archive status, and whether continued use is prohibited or merely discouraged.

310.24 Technical Asset Register Records.

310.24.1 The Corporation shall maintain Technical Asset Register Records, including register custodian records, Asset Identifiers, Asset Names, Asset Classes, Asset Owner records, Asset Steward records, Asset Maintainer records, repository location records, version records, license records, release status records, public-safe status records, confidentiality status records, security status records, dependency status records, vulnerability status records, export-control or controlled technology status records, data / AI / cyber / privacy status records, community safeguards and protected knowledge status records, Nexus interface status records, correction paths, deprecation records, retirement records, corrections, supersessions, withdrawals, and archive records.

---

Section 311. Public-Good Software Stewardship

311.1 Public-Good Software Purpose.

311.1.1 Public-Good Software shall mean software developed, maintained, contributed to, adopted, configured, released, restricted, corrected, superseded, withdrawn, deprecated, retired, or archived by the Corporation to support public-benefit research, evidence integrity, methods, observability, ontology, data governance, AI governance, cybersecurity, verifiable compute, verifiable intelligence, controlled rooms, public authority learning, public-safe publication, community safeguards, technical baselines, and Nexus-compatible interoperability.

311.1.2 Public-Good Software shall be stewarded as technical public-good infrastructure and institutional memory, with controls for scope, quality, security, documentation, license, dependencies, vulnerabilities, release, public-safe use, and correction.

311.1.3 Public-Good Software may be open source, source-available, public, restricted, internal, controlled-room-only, public-authority-restricted, protected-knowledge-restricted, experimental, or archived according to its classification, license, security status, data status, public-safe status, and governance record.

311.2 Software Stewardship Authority.

311.2.1 Software Stewardship Authority shall be exercised by the Board, authorized officers, designated technical governance bodies, asset owners, maintainers, or other competent authorities within recorded delegation.

311.2.2 Stewardship authority may include roadmap approval, repository governance, maintainer designation, release approval, license approval, dependency approval, vulnerability response, public-safe documentation approval, correction, deprecation, retirement, and archive.

311.2.3 No sponsor, provider, vendor, donor, funder, host, public authority participant, national company, Project SPV, capital actor, or enterprise actor shall control Public-Good Software roadmap, release, documentation, findings, public-safe claims, or correction except through accepted, labeled, governed, and public-benefit-compatible program scope that preserves the Corporation’s authority and independence.

311.3 Software Roadmap Governance.

311.3.1 Material Public-Good Software may have a roadmap identifying intended features, priorities, dependencies, security needs, maintenance needs, public authority learning needs, technical baseline needs, public-safe publication needs, and correction priorities.

311.3.2 Roadmaps shall be public-benefit aligned, provider-neutral, sponsor-noncontrolled, resource-aware, security-aware, and consistent with the Corporation’s non-executing role.

311.3.3 Roadmaps shall not be represented as delivery commitments, procurement commitments, public authority commitments, enterprise deployment commitments, service-level obligations, finance-readiness milestones, certification milestones, or recognition milestones unless separately authorized by competent record and accurately limited.

311.4 Software Scope Definition.

311.4.1 Each material Public-Good Software project shall have a defined scope identifying its purpose, intended users, intended environment, supported data classes, prohibited data classes, public-safe status, security assumptions, dependencies, limitations, and correction pathway.

311.4.2 Scope shall distinguish research prototype, reference implementation, production-supporting tool, internal tool, controlled-room tool, dashboard tool, public authority learning tool, evidence tool, AI governance tool, verifiable compute tool, or other software class.

311.4.3 Software shall not be used beyond scope without review and approval.

311.5 Software Use Case Definition.

311.5.1 Each material Public-Good Software project shall define permitted use cases and prohibited use cases.

311.5.2 Permitted use cases may include research support, evidence formatting, schema validation, public-safe publication support, observability support, data quality review, AI governance support, secure repository support, controlled-room support, technical baseline support, or public authority learning support.

311.5.3 Prohibited use cases shall include public warning, emergency command, public authority decision, finance-readiness determination, certification, recognition, procurement approval, provider ranking, legal compliance approval, clinical advice, investment advice, insurance underwriting, operational command, and enterprise execution unless separately and lawfully authorized outside the Corporation’s non-executing role.

311.6 Software Maintainer Assignment.

311.6.1 Material Public-Good Software shall have one or more maintainers assigned by record.

311.6.2 Maintainers shall be responsible for issue triage, code review, dependency management, vulnerability response, documentation, release preparation, correction, deprecation, and archive actions within assigned authority.

311.6.3 Maintainers shall be conflict-reviewed where sponsor, provider, vendor, contributor, public authority, or enterprise interests could affect software direction, release, or public-safe claims.

311.7 Repository Governance.

311.7.1 Public-Good Software repositories shall be governed by access controls, branch controls where appropriate, code review, issue management, contributor rules, license records, dependency review, secret scanning, release controls, vulnerability handling, documentation requirements, and archive rules.

311.7.2 Repository governance shall prevent unauthorized public release, unauthorized deletion, secret exposure, license contamination, dependency compromise, unsupported provider claims, sponsor capture, public authority overclaim, and loss of technical memory.

311.7.3 Public repositories shall not contain confidential data, public authority restricted data, personal information, protected knowledge, credentials, keys, tokens, secrets, unreviewed vulnerabilities, or controlled technology unless public release is lawful, reviewed, and approved.

311.8 Secure Development Lifecycle.

311.8.1 Public-Good Software shall follow a secure development lifecycle proportionate to risk, including planning, design review, threat review where appropriate, secure coding, code review, dependency review, license review, testing, vulnerability review, release approval, documentation, monitoring, patching, correction, and retirement.

311.8.2 Higher-risk software, including software involving public authority data, personal information, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, AI systems, controlled rooms, protected knowledge, or public-facing dashboards, shall require heightened secure development controls.

311.9 Documentation Requirement.

311.9.1 Material Public-Good Software shall include documentation appropriate to its class and release status.

311.9.2 Documentation may include purpose, scope, installation guidance, configuration guidance, data handling rules, AI-use rules, security assumptions, limitations, known issues, public-safe use guidance, license, dependency information, contribution rules, correction path, and non-execution limitations.

311.9.3 Documentation shall not overstate reliability, maturity, security, public authority status, finance-readiness, certification status, procurement status, recognition status, provider endorsement, or operational readiness.

311.10 Release Notes.

311.10.1 Material releases shall include release notes where appropriate.

311.10.2 Release notes shall identify version, date, changes, fixes, security updates, dependency changes, known issues, limitations, migration guidance, public-safe implications, deprecations, and correction path.

311.10.3 Release notes shall not conceal material vulnerabilities, limitations, or breaking changes where disclosure is necessary and public-safe.

311.11 Changelog.

311.11.1 Material Public-Good Software shall maintain a changelog or equivalent version history where appropriate.

311.11.2 The changelog shall identify material changes, additions, removals, fixes, security changes, dependency updates, documentation changes, deprecations, corrections, supersessions, and withdrawals.

311.11.3 Changelogs shall preserve technical memory and shall not be manipulated to erase prior errors, limitations, or reliance history.

311.12 Known Limitations.

311.12.1 Material Public-Good Software documentation shall identify known limitations, including unsupported environments, unsuitable use cases, data limits, AI limits, security limits, privacy limits, scalability limits, jurisdictional limits, public authority limits, public-safe limits, and dependency limits.

311.12.2 Known limitations shall be updated when new limitations are identified through review, user reports, incidents, vulnerabilities, public authority clarification, protected knowledge review, or correction.

311.13 Known Issues.

311.13.1 Material Public-Good Software shall maintain known-issue records appropriate to release status and public-safe needs.

311.13.2 Known issues may include defects, vulnerabilities, compatibility problems, dependency issues, documentation errors, data handling concerns, AI behavior issues, accessibility issues, public-safe wording issues, and boundary risks.

311.13.3 Known issues shall be triaged, assigned, corrected, mitigated, accepted with record, or disclosed where appropriate.

311.14 Dependency Management.

311.14.1 Public-Good Software dependencies shall be identified, reviewed, updated, pinned where appropriate, replaced where necessary, and monitored for vulnerabilities, license conflicts, maintenance risk, supply-chain risk, and compatibility risk.

311.14.2 Dependency choices shall be public-benefit aligned and shall avoid unnecessary provider lock-in, private enclosure, unsupported dependencies, malicious packages, and license conflicts.

311.15 Vulnerability Management.

311.15.1 Public-Good Software shall be subject to vulnerability management proportionate to risk.

311.15.2 Vulnerability management may include vulnerability intake, severity classification, issue restriction, maintainer review, patching, coordinated disclosure, release of security updates, dependency updates, public-safe advisories, and archive updates.

311.15.3 Vulnerability disclosures shall balance transparency, harm reduction, user protection, public authority trust, protected knowledge, and security-sensitive information.

311.16 Public-Safe Use Guidance.

311.16.1 Public-Good Software shall include public-safe use guidance where misuse could create public authority confusion, finance overclaim, certification overclaim, recognition overclaim, procurement overclaim, public warning implication, emergency command implication, provider preference, privacy risk, cyber risk, infrastructure exposure, protected knowledge exposure, or community harm.

311.16.2 Public-safe use guidance shall identify permitted uses, prohibited uses, limitation language, evidence requirements, data classification requirements, AI-use restrictions, publication restrictions, and correction pathways.

311.17 No Software Output as Public Warning, Public Authority Decision, Certification, Procurement Approval, Finance-Readiness, Rating, Recognition, or Provider Preference.

311.17.1 No output, log, receipt, dashboard, score, validation result, evidence pack, benchmark result, AI-assisted result, map, indicator, report, technical baseline alignment output, or message generated by Public-Good Software shall constitute or be represented as public warning, emergency command, public authority decision, certification, procurement approval, finance-readiness, insurance-readiness, rating, recognition, provider preference, legal compliance approval, safety approval, investment suitability, public finance approval, guarantee, or enterprise execution.

311.17.2 Where software outputs may be misunderstood, the Corporation shall require limitation language, interface redesign, output labeling, access restriction, documentation correction, or withdrawal.

311.18 Public-Good Software Records.

311.18.1 The Corporation shall maintain Public-Good Software Records, including software purpose records, stewardship authority records, roadmap records, scope records, use case records, maintainer assignments, repository governance records, secure development lifecycle records, documentation records, release notes, changelogs, known limitation records, known issue records, dependency management records, vulnerability management records, public-safe use guidance, boundary records, corrections, patches, supersessions, withdrawals, deprecations, retirements, and archive records.

---

Section 312. Open Technical Baselines

312.1 Open Technical Baseline Purpose.

312.1.1 Open Technical Baselines shall provide public-good, non-executing, provider-neutral, correctionable reference materials that support interoperability, evidence quality, data governance, AI governance, cybersecurity, observability, public authority learning, Nexus compatibility, public-safe publication, and technical memory.

312.1.2 Open Technical Baselines may include reference fields, schemas, APIs, SDK patterns, data dictionaries, controlled vocabulary, evidence templates, model cards, system cards, benchmark cards, proof-receipt formats, security patterns, AI governance patterns, public authority capacity language, public-safe publication language, observability patterns, dashboard patterns, and documentation conventions.

312.1.3 Open Technical Baselines shall be designed to reduce ambiguity and improve common technical understanding without creating certification, procurement approval, legal compliance approval, provider preference, finance-readiness, recognition, rating, public authority adoption, public warning, emergency command, or enterprise execution.

312.2 Baseline Adoption Authority.

312.2.1 An Open Technical Baseline shall be adopted, amended, superseded, deprecated, withdrawn, retired, or archived only by competent authority under Board-approved policy, officer delegation, technical governance mandate, or other recorded authorization.

312.2.2 Baseline adoption shall identify public-benefit rationale, scope, custodian, effective date, version, public-safe status, license, limitation statement, review cycle, correction path, and affected dependencies.

312.2.3 No sponsor, provider, donor, funder, host, public authority participant, national company, Project SPV, capital actor, or enterprise actor shall control baseline adoption, amendment, release, limitation language, or correction.

312.3 Baseline Scope.

312.3.1 Each Open Technical Baseline shall define its scope, including covered technologies, data classes, evidence classes, systems, workflows, methods, jurisdictions where relevant, public authority contexts, public-safe contexts, and intended users.

312.3.2 Baseline scope shall identify what the baseline does not cover, including excluded technologies, unsupported use cases, prohibited uses, unsuitable reliance contexts, and boundaries with certification, procurement, public authority, finance-readiness, recognition, and enterprise execution.

312.3.3 Baselines shall not be applied outside scope without documented extension, limitation language, and review.

312.4 Baseline Custodian.

312.4.1 Each Open Technical Baseline shall have a Baseline Custodian responsible for maintaining baseline records, versions, documentation, issue intake, correction path, public-safe status, dependency records, review cycles, supersession records, and archive status.

312.4.2 Baseline Custodian status shall not confer authority to certify, approve procurement, recognize, determine finance-readiness, grant public authority adoption, or control enterprise execution.

312.5 Baseline Version.

312.5.1 Each Open Technical Baseline shall be versioned.

312.5.2 Version records shall identify version number, release date, effective date, adoption authority, change rationale, changed components, compatibility with prior versions, migration guidance where appropriate, affected dependencies, public-safe status, and supersession relationship.

312.5.3 Materials relying on an Open Technical Baseline shall identify the applicable version where material to interpretation, interoperability, correction, or public reliance.

312.6 Baseline Effective Date.

312.6.1 Each Open Technical Baseline shall identify an effective date and, where appropriate, a review date, transition date, pilot period, sunset date, or retirement date.

312.6.2 Effective-date records shall prevent confusion between draft, pilot, current, superseded, withdrawn, deprecated, retired, and archived baselines.

312.7 Baseline Review Cycle.

312.7.1 Each Open Technical Baseline shall have a review cycle proportionate to technology change, law change, public authority relevance, data / AI / cyber risk, public-safe publication risk, protected knowledge risk, dependency status, user reliance, and correction history.

312.7.2 Review may be periodic, event-triggered, incident-triggered, vulnerability-triggered, challenge-triggered, public authority clarification-triggered, protected knowledge-triggered, method-triggered, or Board-directed.

312.8 Baseline Public-Safe Status.

312.8.1 Each Open Technical Baseline shall have a Public-Safe Status determining whether it may be publicly released, released to a defined audience, placed in controlled access, restricted, delayed, redacted, withdrawn, or archived.

312.8.2 Public-Safe Status shall be determined through review for privacy, data rights, public authority restrictions, cyber sensitivity, infrastructure sensitivity, protected knowledge, controlled technology, export-control, sanctions, finance-boundary risk, certification-boundary risk, recognition-boundary risk, procurement risk, provider neutrality, public warning implication, emergency-command implication, and misuse risk.

312.9 Baseline Limitation Statement.

312.9.1 Each Open Technical Baseline shall include a limitation statement appropriate to its scope, status, and audience.

312.9.2 Limitation statements shall clarify that the baseline is a public-good reference, not legal advice, professional advice, certification, procurement approval, public authority approval, finance-readiness, recognition, rating, public warning, emergency command, provider endorsement, guarantee, or execution authority.

312.9.3 Limitation statements shall identify known limits, unsupported uses, jurisdictional limits where relevant, technology limits, public-safe limits, validation limits, and correction path.

312.10 Baseline Interoperability Function.

312.10.1 Open Technical Baselines may support interoperability by defining shared structures, fields, formats, vocabulary, schemas, interface patterns, metadata, identifiers, provenance fields, correction fields, public-safe status fields, and boundary language.

312.10.2 Interoperability support shall preserve role separation, legal separateness, data rights, access controls, public authority capacity classification, protected knowledge restrictions, and correction paths.

312.10.3 Interoperability shall not create shared governance, shared liability, agency, partnership, joint venture, shared treasury, certification, procurement approval, recognition, finance-readiness, or public authority adoption.

312.11 Baseline Evidence Quality Function.

312.11.1 Open Technical Baselines may support evidence quality by defining evidence record structures, source-lineage fields, provenance fields, custody fields, timestamp fields, permission fields, authority fields, confidence fields, uncertainty fields, limitation fields, public-safe status fields, review fields, correction fields, and archive fields.

312.11.2 Evidence quality support shall not guarantee evidence truth, completeness, reliability, public-safe status, certification, recognition, finance-readiness, procurement approval, provider preference, public authority approval, public warning, or emergency command.

312.12 Baseline Data Governance Function.

312.12.1 Open Technical Baselines may support data governance by defining data classification structures, data inventory fields, processing register fields, lawful basis fields, consent fields, notice fields, permission fields, access class fields, retention fields, deletion fields, AI-use fields, public authority data fields, protected knowledge fields, and correction fields.

312.12.2 Data governance baseline support shall remain subject to applicable law, contract, public authority restriction, privacy obligation, protected knowledge protocol, security requirement, and institutional policy.

312.13 Baseline AI Governance Function.

312.13.1 Open Technical Baselines may support AI governance by defining model register fields, inference record fields, prompt or prompt-description fields where safe, retrieval source fields, no-training fields, human review fields, bias review fields, hallucination review fields, incident fields, model card structures, system card structures, evaluation record structures, and AI-output limitation language.

312.13.2 AI governance baseline support shall not constitute AI certification, AI safety approval, legal compliance approval, procurement approval, public authority approval, finance-readiness, recognition, rating, or provider endorsement.

312.14 Baseline Cybersecurity Function.

312.14.1 Open Technical Baselines may support cybersecurity by defining secure development patterns, repository controls, access-control structures, logging fields, vulnerability handling, SBOM fields where appropriate, artifact signing patterns where appropriate, incident record fields, secret-management patterns, dependency review practices, secure release practices, and public-safe vulnerability communication.

312.14.2 Cybersecurity baseline support shall not constitute managed security service, cyber certification, security guarantee, cyber insurance underwriting, legal compliance approval, public authority cyber command, public warning, or emergency command.

312.15 Baseline Observability Function.

312.15.1 Open Technical Baselines may support observability by defining evidence intake fields, telemetry fields, sensor record fields, degraded-mode status fields, resilience indicator fields, dashboard structures, public-safe mapping fields, node / hub / cluster / hotspot conventions, regional cluster conventions, national dense core conventions, and correction fields.

312.15.2 Observability baseline support shall not constitute public warning, emergency command, public authority decision, operational control, provider certification, recognition, finance-readiness, procurement approval, or rating.

312.16 Baseline Public Authority Learning Function.

312.16.1 Open Technical Baselines may support public authority learning by providing technical literacy structures, evidence literacy fields, methods literacy guides, public-safe interpretation aids, capacity-classification language, public authority data fields, and boundary limitation language.

312.16.2 Public authority learning support shall not constitute official guidance, regulation, procurement criteria, grant criteria, public finance approval, emergency instruction, public warning, public authority decision, or sovereign obligation unless separately issued by a competent public authority through lawful process.

312.17 Baseline Nexus Compatibility Support Function.

312.17.1 Open Technical Baselines may support Nexus compatibility by aligning evidence records, methods records, observability records, ontology records, public-safe reports, proof receipts, Docket inputs, Grid inputs, GRF-facing inputs, GRA-facing inputs, public-good software, controlled-room outputs, public authority learning materials, and technical repositories with Nexus-compatible formats and concepts.

312.17.2 Nexus compatibility support shall be limited to technical alignment, semantic alignment, evidence format alignment, public-good stack alignment, or interface readiness as supported by record.

312.17.3 Nexus compatibility support shall not imply GRF recognition, GRA finance-readiness, certification, procurement approval, public authority approval, provider preference, public-good approval, enterprise approval, or execution authority.

312.18 No Baseline as Certification.

312.18.1 An Open Technical Baseline shall not constitute certification, accreditation, conformance approval, safety approval, legal compliance approval, cybersecurity compliance approval, privacy compliance approval, AI safety approval, professional approval, provider qualification, procurement qualification, or warranty.

312.18.2 No person shall represent alignment with, implementation of, contribution to, or use of an Open Technical Baseline as certification by the Corporation.

312.19 No Baseline as Procurement Mandate.

312.19.1 An Open Technical Baseline shall not constitute a procurement mandate, procurement specification, preferred provider list, vendor qualification, public contract requirement, grant requirement, public-private partnership condition, or purchasing recommendation.

312.19.2 Public authorities, sponsors, providers, national companies, Project SPVs, enterprise actors, and other persons shall not cite Open Technical Baseline alignment as procurement approval by the Corporation.

312.20 No Baseline as Legal Compliance Approval.

312.20.1 An Open Technical Baseline shall not constitute legal advice, regulatory advice, professional advice, legal compliance approval, privacy compliance approval, cybersecurity compliance approval, AI compliance approval, public records compliance approval, procurement compliance approval, export-control determination, sanctions determination, tax determination, or fiduciary advice.

312.20.2 Baselines shall include limitation language where legal or professional reliance risk is reasonably foreseeable.

312.21 No Baseline as Provider Preference.

312.21.1 An Open Technical Baseline shall not prefer, endorse, rank, approve, recommend, validate, or qualify any provider, vendor, sponsor, donor, funder, host, technology, product, service, platform, protocol, national company, Project SPV, capital actor, or enterprise actor.

312.21.2 Provider or sponsor contributions to a baseline shall be disclosed, restricted, ring-fenced, or refused where necessary to preserve provider neutrality, sponsor non-control, and public trust.

312.22 Open Technical Baseline Records.

312.22.1 The Corporation shall maintain Open Technical Baseline Records, including baseline purpose records, adoption authority records, scope records, custodian records, version records, effective-date records, review-cycle records, public-safe status records, limitation statements, interoperability function records, evidence quality function records, data governance function records, AI governance function records, cybersecurity function records, observability function records, public authority learning function records, Nexus compatibility support records, certification-boundary records, procurement-boundary records, legal-compliance-boundary records, provider-neutrality records, corrections, supersessions, withdrawals, deprecations, retirements, and archive records.

Section 313. Reference Architectures, Technical Profiles, Schemas, APIs, SDKs, and Interoperability Interfaces

313.1 Reference Architecture Purpose.

313.1.1 Reference Architectures shall provide non-executing, public-good, provider-neutral, public-safe, correctionable design support for the structuring of evidence systems, data systems, observability systems, AI governance systems, cybersecurity controls, public-good software, controlled rooms, dashboards, maps, verifiable compute workflows, verifiable intelligence workflows, technical baselines, public authority learning environments, and Nexus-compatible institutional and technical interfaces.

313.1.2 Reference Architectures may describe components, relationships, workflows, control layers, governance checkpoints, data flows, metadata flows, trust boundaries, public-safe publication boundaries, access-control patterns, evidence-handling patterns, public authority capacity patterns, protected knowledge safeguards, correction paths, and interoperability assumptions.

313.1.3 Reference Architectures shall not be represented as engineering certification, professional design approval, procurement specification, public authority standard, enterprise deployment approval, security guarantee, finance-readiness, recognition, legal compliance approval, public warning, emergency command, or operational mandate.

313.2 Technical Profile Purpose.

313.2.1 Technical Profiles shall define structured, versioned, public-good technical specifications, metadata expectations, field requirements, validation rules, interoperability assumptions, data classifications, public-safe status fields, evidence support fields, limitation fields, correction fields, and boundary-language elements for specific technical asset classes, evidence classes, system interfaces, observability contexts, or Nexus-compatible workflows.

313.2.2 Technical Profiles shall support consistency, reviewability, public-safe interoperability, machine readability where appropriate, human readability, correctionability, and semantic alignment across Corporation materials and Nexus-facing technical assets.

313.2.3 Technical Profiles shall be scoped, documented, versioned, validated where appropriate, public-safe reviewed, corrected when necessary, and deprecated or retired when obsolete, unsafe, unsupported, misleading, or superseded.

313.3 Schema Purpose.

313.3.1 Schemas shall provide formal or semi-formal structures for organizing data, evidence records, methods records, ontology records, observability records, public authority capacity records, inference records, compute workload records, proof receipts, dashboards, maps, public-good software, technical baselines, controlled-room records, correction records, and Nexus-facing materials.

313.3.2 Schemas may specify required fields, optional fields, field types, permissible values, identifiers, timestamps, provenance fields, source-lineage fields, access classes, data classes, AI-use classes, public-safe classes, jurisdiction fields, authority records, limitation fields, confidence fields, uncertainty fields, review fields, and correction fields.

313.3.3 Schemas shall be governed as interoperability instruments and shall not imply certification, recognition, finance-readiness, procurement approval, public authority adoption, legal compliance approval, provider qualification, or execution authority.

313.4 API Purpose.

313.4.1 APIs may be created or adopted to support controlled, documented, secure, and versioned technical exchange among public-good software, evidence systems, data systems, observability systems, dashboards, maps, controlled rooms, repositories, validation workflows, proof-receipt systems, public authority learning tools, and Nexus-compatible interfaces.

313.4.2 APIs shall be governed through access control, authentication, authorization, rate limiting where appropriate, logging where appropriate, data classification, privacy review, AI-use review, cybersecurity review, public-safe documentation, versioning, deprecation rules, incident response, and correction pathways.

313.4.3 API access shall not create entitlement to data, production service, operational reliance, public authority integration, procurement approval, provider preference, certification, recognition, finance-readiness, or service-level commitment except where separately and lawfully agreed by competent authority.

313.5 SDK Purpose.

313.5.1 SDKs may be developed or adopted to support implementation of schemas, APIs, validation workflows, evidence formats, public-good software patterns, proof-receipt workflows, verifiable compute workflows, dashboards, maps, public authority learning tools, and Nexus-compatible technical interfaces.

313.5.2 SDKs shall include documentation, version information, license information, dependency information, security guidance, permitted-use guidance, prohibited-use guidance, public-safe limitation language, correction path, and deprecation information where appropriate.

313.5.3 SDK availability shall not constitute product endorsement, provider qualification, procurement approval, certification, recognition, finance-readiness, public authority adoption, or guarantee that an implementation is correct, secure, lawful, or public-safe.

313.6 Interoperability Interface Purpose.

313.6.1 Interoperability Interfaces shall support lawful, controlled, semantically clear, technically consistent, public-safe, and correctionable exchange of records, metadata, proofs, logs, dashboards, maps, evidence packs, methods, baselines, public authority learning materials, and other technical assets among approved systems or participants.

313.6.2 Interoperability Interfaces shall preserve role separation, institutional separateness, data rights, access controls, public authority capacity classification, protected knowledge restrictions, public-safe publication status, finance-boundary discipline, certification-boundary discipline, recognition-boundary discipline, procurement neutrality, provider neutrality, and correctionability.

313.6.3 Interoperability shall not create shared governance, shared treasury, agency, partnership, joint venture, shared liability, public authority delegation, recognition authority, finance-readiness authority, certification authority, procurement authority, or enterprise execution.

313.7 Evidence Metadata Profile.

313.7.1 An Evidence Metadata Profile may define metadata fields for evidence records, including source, source lineage, provenance, custody, timestamp, version, data class, evidence class, permission, authority, data rights, contributor capacity, public authority capacity where applicable, confidence, uncertainty, limitation, review status, public-safe status, access class, correction path, supersession status, withdrawal status, and archive status.

313.7.2 Evidence Metadata Profiles shall support evidence integrity and correctionability and shall not convert evidence into recognition, finance-readiness, certification, procurement approval, public authority decision, public warning, emergency command, rating, or provider preference.

313.8 Method Profile.

313.8.1 A Method Profile may define metadata and structural requirements for methods, including method purpose, owner, custodian, adoption authority, scope, inputs, outputs, assumptions, limitations, validation status, public-safe status, version, effective date, review cycle, correction path, retirement status, supersession status, and archive status.

313.8.2 Method Profiles shall support method stewardship, reproducibility where appropriate, reviewability, public-safe publication, and correctionability.

313.9 Ontology Profile.

313.9.1 An Ontology Profile may define structures for taxonomies, controlled vocabularies, data dictionaries, evidence classes, risk categories, technology families, maturity concepts, public authority capacity concepts, finance boundary concepts, certification boundary concepts, recognition boundary concepts, procurement boundary concepts, Nexus-compatible claim concepts, and semantic mappings.

313.9.2 Ontology Profiles shall preserve semantic discipline, reduce drift, support AI-readable knowledge structures where appropriate, and prevent terms from being misused to imply approval, recognition, finance-readiness, certification, procurement approval, or public authority action.

313.10 Dataset Profile.

313.10.1 A Dataset Profile may define fields for dataset identity, title, owner, custodian, source, source authority, collection method, lawful basis, permissions, license, data dictionary, schema, version, data classes, sensitive fields, transformations, quality review, missingness, bias review, representativeness, public-safe status, AI-use status, access class, retention, deletion, correction path, and archive status.

313.10.2 Dataset Profiles shall support lawful use, data quality, privacy, AI governance, public-safe publication, and correctionability.

313.11 Model Register Profile.

313.11.1 A Model Register Profile may define fields for model identity, model family, model provider, deployment environment, version, owner, custodian, approved use, prohibited use, permitted data classes, prohibited data classes, no-training status, inference logging, risk class, evaluation status, known limitations, incident history, monitoring status, retirement status, and correction path.

313.11.2 Model Register Profiles shall support AI governance and shall not imply model certification, AI safety approval, legal compliance approval, procurement approval, public authority approval, finance-readiness, recognition, rating, or provider endorsement.

313.12 Inference Record Profile.

313.12.1 An Inference Record Profile may define fields for material AI output records, including source inputs, prompt or prompt description where safe, retrieval sources, model identity, model version, inference date, user or workflow, purpose, data class, access class, output, reviewer, review status, hallucination review, bias review, limitation, confidence, public-safe status, correction path, and downstream dependency.

313.12.2 Inference Record Profiles shall support verifiable intelligence and prevent AI outputs from being treated as source-grounded technical truth without records and human review.

313.13 Compute Workload Profile.

313.13.1 A Compute Workload Profile may define fields for computational work, including input data, authority, environment, code, tool, model, workflow, version, execution parameters, execution time, job identifier, logs, output, reviewer, confidence, limitation, classification, correction path, and archive status.

313.13.2 Compute Workload Profiles shall support verifiable compute, reproducibility where appropriate, auditability where lawful and safe, cybersecurity, and correctionability.

313.14 Proof Receipt Profile.

313.14.1 A Proof Receipt Profile may define fields for receipt identity, workflow step, input reference, timestamp, version, actor or system, authority, custody, hash or signature where applicable, review status, limitation, confidence, public-safe status, correction path, and scope.

313.14.2 Proof Receipt Profiles shall make clear that proof receipts evidence recorded workflow conditions and shall not by themselves establish substantive truth, certification, recognition, finance-readiness, procurement approval, public authority decision, rating, public warning, emergency command, or execution authority.

313.15 Observatory Node Profile.

313.15.1 An Observatory Node Profile may define fields for node identity, node type, custodian, jurisdiction, technology coverage, evidence sources, public authority context, community context, protected knowledge status, data classes, observability methods, telemetry classes, sensor classes, dashboard outputs, public-safe status, degraded-mode status, resilience indicators, correction path, and archive status.

313.15.2 Observatory Node Profiles shall preserve evidence discipline, public-safe mapping, public authority boundaries, protected knowledge safeguards, and non-execution.

313.16 Nexus Hub, Nexus Cluster, Nexus Hotspot, Regional Cluster, and National Dense Nexus Core Profiles.

313.16.1 Nexus Hub, Nexus Cluster, Nexus Hotspot, Regional Cluster, and National Dense Nexus Core Profiles may define technical and governance fields for aggregation, federation, comparison, cross-jurisdictional observability, systemic risk context, technology coverage, public authority capacity, community safeguards, evidence classes, telemetry classes, degraded-mode status, resilience indicators, data / AI / cyber controls, public-safe publication controls, and correction paths.

313.16.2 These Profiles shall prevent false uniformity, jurisdictional flattening, unsupported risk ranking, public warning implication, emergency command implication, public authority overclaim, finance overclaim, certification overclaim, recognition overclaim, procurement overclaim, and provider preference.

313.17 AI-RAN / O-RAN Signal Profile.

313.17.1 An AI-RAN / O-RAN Signal Profile may define fields for radio, network, RIC, edge compute, telemetry, slicing, anomaly, resilience, performance, configuration, timing, synchronization, privacy, cyber integrity, provider context, public authority context, signal confidence, limitation, public-safe status, and correction path.

313.17.2 AI-RAN / O-RAN Signal Profiles shall not be used to certify network performance, approve telecom procurement, guarantee coverage, issue public safety readiness, rank providers, or operate telecom infrastructure.

313.18 DePIN and DLT Telemetry Profile.

313.18.1 A DePIN and DLT Telemetry Profile may define fields for node identity, proof record, ledger reference, oracle source, off-chain evidence, timestamp, participation record, uptime record, location assertion, incentive context, token-related risk, Sybil risk, spoofing risk, governance context, confidence, limitation, public-safe status, and correction path.

313.18.2 DePIN and DLT Telemetry Profiles shall not be represented as token endorsement, investment signal, finance-readiness, public authority approval, network certification, procurement approval, or guarantee of ledger truth.

313.19 Digital Twin Output Profile.

313.19.1 A Digital Twin Output Profile may define fields for model identity, scenario, assumptions, source data, calibration status, validation status, uncertainty, real-world evidence linkage, simulation date, output type, public authority context, public-safe status, limitation, correction path, and archive status.

313.19.2 Digital Twin Output Profiles shall preserve the distinction between modeled output, observed evidence, forecast, scenario, assumption, and public authority decision.

313.20 Cyber Telemetry Profile.

313.20.1 A Cyber Telemetry Profile may define fields for log type, source system, timestamp, event type, identity context, access context, integrity status, incident linkage, vulnerability linkage, confidentiality status, public authority restriction, cyber-sensitive classification, reviewer, public-safe status, limitation, and correction path.

313.20.2 Cyber Telemetry Profiles shall be handled under cybersecurity, privacy, public authority data, and public-safe publication controls and shall not create cyber certification, legal compliance approval, public warning, emergency command, or managed security service status.

313.21 Public-Safe Dashboard and Public-Safe Map Profiles.

313.21.1 Public-Safe Dashboard and Public-Safe Map Profiles may define fields and controls for data source, evidence support, aggregation level, geospatial resolution, time delay, redaction, masking, sensitive-location handling, protected knowledge status, public authority capacity language, accessibility, limitation language, confidence, uncertainty, correction path, and withdrawal path.

313.21.2 Such Profiles shall prevent dashboards and maps from being misread as public warnings, emergency commands, public authority decisions, ratings, recognition, finance-readiness, procurement approval, provider preference, or operational instructions.

313.22 Federation Interface Profile.

313.22.1 A Federation Interface Profile may define fields and controls for lawful, role-separated, records-supported, public-safe interoperability among GCRI US, GCRI Canada, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Standards, Nexus Observatory, Nexus Rails, Nexus Grid, Nexus Academy, consortiums, national companies, Project SPVs, public authorities, providers, sponsors, hosts, universities, laboratories, communities, and other participants.

313.22.2 Federation Interface Profiles shall define institutional identity, authority, capacity, data rights, permitted exchange, prohibited exchange, public-safe status, correction path, access class, semantic mapping, and boundary limitations.

313.22.3 Federation shall not create shared governance, shared treasury, agency, partnership, joint venture, public authority delegation, recognition authority, finance-readiness authority, certification authority, procurement authority, or execution authority.

313.23 Versioning, Validation, Deprecation, and Correction.

313.23.1 Reference Architectures, Technical Profiles, Schemas, APIs, SDKs, and Interoperability Interfaces shall be versioned where material to reliance, interoperability, release, public-safe publication, correction, or technical memory.

313.23.2 Validation shall assess structural correctness, field completeness, semantic consistency, data-rights alignment, public-safe status, security, privacy, AI-use implications, protected knowledge implications, and boundary language where applicable.

313.23.3 Deprecation or retirement shall occur where an architecture, profile, schema, API, SDK, or interface is obsolete, unsafe, unsupported, misleading, insecure, superseded, incompatible, non-public-safe, or inconsistent with this Bylaw.

313.23.4 Corrections shall identify affected versions, affected downstream dependencies, correction reason, public-safe implications, replacement status, and archive status.

313.24 No Technical Profile as Certification, Procurement Approval, Public Authority Adoption, Finance-Readiness, Rating, or Recognition.

313.24.1 No Reference Architecture, Technical Profile, Schema, API, SDK, Interoperability Interface, Evidence Metadata Profile, Method Profile, Ontology Profile, Dataset Profile, Model Register Profile, Inference Record Profile, Compute Workload Profile, Proof Receipt Profile, Observatory Profile, signal profile, telemetry profile, digital twin profile, dashboard profile, map profile, or federation profile shall constitute or be represented as certification, accreditation, procurement approval, public authority adoption, finance-readiness, insurance-readiness, rating, recognition, provider qualification, legal compliance approval, public warning, emergency command, guarantee, or execution authority.

313.24.2 Any use of such assets shall include limitation language where necessary to prevent overclaim.

313.25 Reference Architecture, Profile, Schema, API, SDK, and Interface Records.

313.25.1 The Corporation shall maintain Reference Architecture, Profile, Schema, API, SDK, and Interface Records, including architecture purpose records, Technical Profile records, schema records, API records, SDK records, interface records, Evidence Metadata Profiles, Method Profiles, Ontology Profiles, Dataset Profiles, Model Register Profiles, Inference Record Profiles, Compute Workload Profiles, Proof Receipt Profiles, Observatory Node Profiles, hub / cluster / hotspot / regional / national dense core profiles, AI-RAN / O-RAN Signal Profiles, DePIN and DLT Telemetry Profiles, Digital Twin Output Profiles, Cyber Telemetry Profiles, Public-Safe Dashboard and Map Profiles, Federation Interface Profiles, version records, validation records, deprecation records, correction records, limitation records, supersession records, withdrawal records, and archive records.

---

Section 314. Intellectual Property Ownership

314.1 Intellectual Property Ownership Purpose.

314.1.1 Intellectual Property ownership rules shall protect the Corporation’s public-benefit mission, legal rights, public-good technical assets, software, open technical baselines, schemas, APIs, SDKs, documentation, research outputs, data rights, model rights, public-safe publications, technical memory, and capacity to preserve, license, correct, release, restrict, archive, and steward public-good work.

314.1.2 Intellectual Property ownership shall be governed by applicable law, written agreements, contributor terms, employment terms, contractor agreements, fellowship terms, volunteer agreements where used, grant terms, sponsorship terms, collaboration agreements, data-sharing agreements, licenses, Board policy, and this Bylaw.

314.1.3 Intellectual Property governance shall preserve mission-aligned public-good availability while protecting confidential information, protected knowledge, public authority restrictions, data rights, cybersecurity, privacy, controlled technology, export-control, sanctions, and correctionability.

314.2 Works Created by Employees.

314.2.1 Works created by employees within the scope of employment, using Corporation resources, at the Corporation’s direction, or for Corporation purposes shall be owned by the Corporation to the fullest extent permitted by law and applicable agreements.

314.2.2 Employee-created works may include software, code, documentation, research outputs, methods, schemas, data dictionaries, technical baselines, model cards, system cards, benchmark cards, dashboards, maps, training materials, publications, designs, workflows, and other technical or creative materials.

314.2.3 Employment agreements or policy may require assignment, confidentiality, moral rights waiver where lawful, invention disclosure, publication review, and cooperation in registration, enforcement, correction, and licensing.

314.3 Works Created by Contractors.

314.3.1 Works created by contractors shall be owned, licensed, assigned, or otherwise controlled according to the applicable contractor agreement.

314.3.2 Contractor agreements should specify whether work is work made for hire where legally available, assigned to the Corporation, licensed to the Corporation, jointly owned, or retained by the contractor with defined usage rights.

314.3.3 Contractor-created works shall not be incorporated into Corporation technical assets unless IP ownership, license rights, confidentiality, data rights, AI-use rights, open-source obligations, moral rights where applicable, and public-good release rights are sufficient for the intended use.

314.4 Works Created by Fellows.

314.4.1 Works created by fellows shall be governed by fellowship agreements, program terms, research protocols, contributor terms, collaboration agreements, institutional policies, and applicable law.

314.4.2 Fellowship terms should define ownership or license treatment for research outputs, software, datasets, documentation, methods, publications, technical baselines, and other contributions.

314.4.3 Fellows shall not assume that fellowship participation creates personal ownership over public-good technical assets, nor shall the Corporation assume ownership absent applicable agreement, law, or assignment.

314.5 Works Created by Advisors.

314.5.1 Works created by advisors shall be governed by advisor agreements, contribution terms, confidentiality terms, Board or officer approvals, and applicable law.

314.5.2 Advisor contributions may be treated as advisory input, assigned work, licensed work, joint work, or retained pre-existing expertise depending on the applicable record.

314.5.3 Advisor participation shall not transfer advisor pre-existing materials to the Corporation unless expressly agreed, and shall not grant the advisor control over Corporation publications, technical baselines, software, or public meaning.

314.6 Works Created by Volunteers.

314.6.1 Works created by volunteers shall be governed by volunteer agreements, contributor terms, program rules, repository contribution terms, or other recorded arrangements.

314.6.2 Volunteer contributions shall not be accepted into material Corporation assets unless the Corporation has rights sufficient to use, modify, distribute, publish, correct, supersede, withdraw, relicense where allowed, and archive the contribution for the intended public-good purpose.

314.6.3 Volunteer status shall not create authority to bind the Corporation, change institutional meaning, publish on behalf of the Corporation, or approve public-good technical assets.

314.7 Works Created by Technical Contributors.

314.7.1 Works created by technical contributors, including open-source contributors, repository participants, standards-support contributors, schema contributors, documentation contributors, code contributors, issue contributors, and pull request contributors, shall be governed by contributor terms, contributor license agreements, developer certificates of origin, assignment instruments, repository terms, or other applicable records.

314.7.2 Technical contributors shall represent that they have the right to contribute the work and that the contribution does not knowingly violate third-party rights, confidentiality obligations, public authority restrictions, protected knowledge restrictions, controlled technology restrictions, or license obligations.

314.7.3 The Corporation may reject, revert, rewrite, restrict, or remove contributions where rights are unclear, provenance is inadequate, license terms conflict, security risk exists, protected knowledge is implicated, or public-safe release is not supportable.

314.8 Works Created by Maintainers.

314.8.1 Maintainer-created works shall be governed by the maintainer’s underlying relationship to the Corporation, including employment, contractor, fellowship, volunteer, contributor, advisor, or institutional partner status, and applicable contributor or assignment terms.

314.8.2 Maintainer authority to review, merge, release, correct, or deprecate technical assets shall not determine ownership unless supported by agreement or law.

314.8.3 Maintainers shall preserve attribution, license compliance, provenance records, public-safe release controls, and correction pathways.

314.9 Works Created by Grantees or Sponsored Participants.

314.9.1 Works created by grantees, sponsored participants, funded researchers, sponsored fellows, or participants supported by restricted funds shall be governed by grant terms, sponsorship terms, research agreements, program terms, contributor terms, institutional policies, and applicable law.

314.9.2 Funding support shall not by itself transfer ownership to the sponsor, donor, funder, grantee, or Corporation unless the governing instrument provides so.

314.9.3 Sponsor or funder support shall not confer control over publication, licensing, correction, public-safe framing, technical baseline content, software roadmap, or institutional meaning.

314.10 Joint Works.

314.10.1 Joint Works may arise only where law and record support joint authorship, joint inventorship, joint ownership, or jointly licensed rights.

314.10.2 Joint Works shall be governed by written or otherwise reliable records specifying ownership shares where applicable, licensing rights, publication rights, confidentiality, enforcement, revenue treatment where applicable, public-good release rights, correction rights, withdrawal rights, and dispute resolution.

314.10.3 The Corporation shall avoid ambiguous joint ownership where it could impair public-good release, correctionability, repository governance, public-safe publication, or role separation.

314.11 Commissioned Works.

314.11.1 Commissioned Works shall be governed by written agreements specifying ownership, assignment, license, work-made-for-hire status where legally available, payment, deliverables, acceptance, confidentiality, data rights, moral rights where applicable, third-party materials, open-source components, and public-good release rights.

314.11.2 Commissioned Works shall not be accepted into Corporation assets unless rights are sufficient for intended use, modification, publication, licensing, correction, supersession, withdrawal, and archive.

314.12 Pre-Existing Materials.

314.12.1 Pre-Existing Materials remain owned by their original owner unless assigned or otherwise transferred by written agreement.

314.12.2 Any use of Pre-Existing Materials in Corporation work shall identify ownership, license, permitted uses, restrictions, attribution, confidentiality, derivative-work rights, sublicensing rights, AI-use rights, public release rights, and correction rights where material.

314.12.3 Pre-Existing Materials shall not be incorporated into open technical baselines, public-good software, public-safe publications, dashboards, maps, or Nexus-facing materials where restrictions prevent intended public-good use or correction.

314.13 Derivative Works.

314.13.1 Derivative Works shall be governed by the rights applicable to the underlying work, applicable license terms, contributor terms, assignment instruments, and the Corporation’s public-good mission requirements.

314.13.2 Derivative Works shall not be created, published, licensed, released, or incorporated where the Corporation lacks rights to do so or where doing so would violate license obligations, confidentiality, public authority restrictions, protected knowledge restrictions, export-control, sanctions, or data rights.

314.14 Data Rights.

314.14.1 Data Rights include rights and restrictions relating to collection, access, use, processing, transformation, publication, sharing, licensing, retention, deletion, AI processing, embeddings, model training, model improvement, derived data, synthetic data, and archive.

314.14.2 Data Rights shall be recorded for material datasets and sensitive data classes and shall be distinguished from copyright, database rights, confidentiality obligations, privacy obligations, public authority restrictions, protected knowledge restrictions, and contractual restrictions.

314.15 Model Rights.

314.15.1 Model Rights include rights and restrictions relating to model artifacts, model weights, fine-tuned models, embeddings, prompts, system instructions, evaluation outputs, model cards, system cards, benchmark results, and model-generated outputs.

314.15.2 Model Rights shall be reviewed before model use, release, fine-tuning, public benchmarking, publication, redistribution, integration, or incorporation into public-good technical assets.

314.16 Software Rights.

314.16.1 Software Rights include copyright, license rights, contribution rights, dependency rights, patent rights, trade secret rights, source-code rights, object-code rights, documentation rights, database rights where applicable, and release rights.

314.16.2 Software Rights shall be reviewed before release, redistribution, integration, sublicensing, publication, deployment, transfer, or incorporation into public-good software.

314.17 Documentation Rights.

314.17.1 Documentation Rights include rights relating to text, diagrams, screenshots, examples, tutorials, model cards, system cards, benchmark cards, dataset cards, implementation guides, public authority learning materials, technical baselines, release notes, and public-safe guidance.

314.17.2 Documentation shall not include third-party copyrighted materials, confidential materials, protected knowledge, public authority restricted materials, screenshots, images, or diagrams without appropriate rights and public-safe review.

314.18 Research Output Rights.

314.18.1 Research Output Rights include rights relating to reports, papers, methods, datasets, analysis, figures, charts, maps, dashboards, code, models, evidence packs, technical baselines, publications, and related materials.

314.18.2 Research Output Rights shall be governed consistently with research integrity, sponsor non-control, publication independence, confidentiality, data rights, ethics review, public authority restrictions, protected knowledge safeguards, and correctionability.

314.19 Public-Good Mission Overlay.

314.19.1 All Intellectual Property ownership and rights decisions shall be interpreted through the Corporation’s public-good mission, nonprofit character, non-executing role, public-benefit purpose, technical memory obligations, correctionability, public-safe publication discipline, and Nexus public-good stack role.

314.19.2 The Corporation may prefer open, permissive, public-good, defensive, or standards-support licensing where consistent with law, mission, security, privacy, protected knowledge, public authority restrictions, sustainability, and public-safe release.

314.19.3 Public-good mission shall not require release of confidential, restricted, privileged, cyber-sensitive, infrastructure-sensitive, personal, health-sensitive, controlled technology, public authority restricted, community-protected, Tribal / Indigenous, or protected knowledge materials.

314.20 Contract Terms Control Where Lawful and Recorded.

314.20.1 Written contract terms, grant terms, sponsorship terms, employment terms, contributor terms, license terms, public authority terms, data-sharing terms, and collaboration terms shall control ownership and rights where lawful, recorded, and not inconsistent with mandatory law.

314.20.2 Where this Bylaw and a contract appear inconsistent, competent authority shall interpret the instruments to preserve lawful rights, mission alignment, public-good stewardship, confidentiality, data protection, public authority restrictions, protected knowledge safeguards, and correctionability.

314.21 IP Ownership Records.

314.21.1 The Corporation shall maintain IP Ownership Records, including employee work records, contractor work records, fellow work records, advisor work records, volunteer work records, contributor records, maintainer records, grantee or sponsored participant records, joint work records, commissioned work records, pre-existing material records, derivative work records, data rights records, model rights records, software rights records, documentation rights records, research output rights records, public-good mission overlay records, contract-control records, assignments, licenses, contributor terms, moral rights records where applicable, corrections, disputes, and archive records.

---

Section 315. Copyright, Patent, Trademark, Trade Secret, Database, Data, Model, and Technical Asset Rights

315.1 Copyright Stewardship.

315.1.1 The Corporation shall steward copyrights in software, documentation, publications, reports, diagrams, schemas, technical baselines, dashboards, maps, training materials, public authority learning materials, model cards, system cards, dataset cards, benchmark cards, evaluation materials, and other copyrightable works consistent with its public-benefit purposes.

315.1.2 Copyright stewardship may include ownership, licensing, permission management, attribution, registration where appropriate, enforcement where necessary, open licensing, public-good release, correction, withdrawal, and archive.

315.1.3 Copyright shall not be asserted in a manner inconsistent with the Corporation’s public-good mission unless protection is necessary to prevent misuse, misrepresentation, private enclosure, unlawful exploitation, protected knowledge exposure, or harm.

315.2 Patent Stewardship.

315.2.1 Patent stewardship shall govern inventions, patentable methods, technical systems, software-related inventions where protectable, hardware-related inventions, AI governance methods, verifiable compute methods, observability methods, cybersecurity methods, and other patent-relevant outputs.

315.2.2 The Corporation may pursue defensive publication, open patent commitments, patent non-assertion, assignment, licensing, or patent protection where consistent with mission, public-good availability, anti-enclosure, sponsor non-control, provider neutrality, public authority trust, and sustainability.

315.2.3 Patent strategy shall not be used to create private monopoly over public-good technical assets, block public-benefit interoperability, or allow sponsors or providers to capture Corporation-developed public-good methods.

315.3 Trademark and Mark Stewardship.

315.3.1 The Corporation shall steward its name, marks, logos, program names, asset names, publication names, repository names, technical baseline names, software names, and Nexus-compatible terminology to prevent confusion, misuse, false endorsement, false certification, false recognition, false finance-readiness, false procurement approval, false public authority adoption, and public-safe misrepresentation.

315.3.2 Use of Corporation marks may be permitted only under approved guidelines, licenses, acknowledgments, contributor terms, sponsorship terms, or publication rules.

315.3.3 No person shall use the Corporation’s marks to imply approval, partnership, public authority status, GRF recognition, GRA finance-readiness, certification, procurement approval, provider preference, rating, public warning, emergency command, or execution authority.

315.4 Trade Secret Stewardship.

315.4.1 Trade Secret stewardship shall protect confidential technical, operational, security, financial, strategic, repository, model, data, public authority, vulnerability, controlled-room, and protected knowledge materials where secrecy is lawful, mission-aligned, and necessary.

315.4.2 The Corporation may protect trade secrets through confidentiality agreements, access controls, controlled rooms, secure repositories, limited disclosure, employee and contractor duties, vendor terms, and incident response.

315.4.3 Trade secret protection shall not be used to conceal misconduct, suppress required correction, avoid required notification, or improperly privatize public-good assets that have been approved for open public-good release.

315.5 Database Rights Where Applicable.

315.5.1 Database rights, compilation rights, sui generis database rights where applicable, and other database-related protections shall be managed according to applicable law, licenses, contracts, data rights, public authority restrictions, and public-good mission.

315.5.2 Database rights shall be distinguished from rights in underlying data, privacy obligations, protected knowledge restrictions, public authority restrictions, copyright, confidentiality, and contractual obligations.

315.6 Data Rights.

315.6.1 Data Rights shall be governed as a distinct rights category covering authority to collect, receive, store, process, transform, analyze, classify, publish, share, license, retain, delete, archive, train on, embed, infer from, or derive from data.

315.6.2 Data Rights shall be recorded and enforced according to source, contributor, license, consent, public authority permission, contract, law, community protocol, Tribal / Indigenous protocol, protected knowledge restriction, privacy obligation, AI-use restriction, and public-safe status.

315.7 Dataset Rights.

315.7.1 Dataset Rights shall govern datasets assembled, licensed, received, created, derived, synthesized, purchased, contributed, or published by the Corporation.

315.7.2 Dataset Rights shall include source rights, license terms, attribution, redistribution, derivative use, AI-use rights, publication rights, commercial-use restrictions, public authority restrictions, privacy obligations, protected knowledge restrictions, and correction obligations.

315.8 Synthetic Data Rights.

315.8.1 Synthetic Data Rights shall govern synthetic data generated by or for the Corporation, including rights in generation methods, source dependencies, model outputs, use restrictions, publication rights, and correction obligations.

315.8.2 Synthetic data shall not be assumed unrestricted merely because it is artificially generated. Source-data restrictions, privacy risks, protected knowledge leakage, public authority restrictions, and model provider terms may continue to apply.

315.9 Derived Data Rights.

315.9.1 Derived Data Rights shall govern data created through transformation, aggregation, calculation, inference, summarization, enrichment, linkage, normalization, de-identification, pseudonymization, geospatial processing, AI processing, or model output.

315.9.2 Derived data shall remain subject to source restrictions, data rights, public authority restrictions, protected knowledge restrictions, privacy obligations, AI-use restrictions, license terms, and correction duties unless competent review determines otherwise.

315.10 Embedding and Vector Store Rights.

315.10.1 Embedding and Vector Store Rights shall govern embeddings, vector representations, semantic indexes, retrieval indexes, similarity-search stores, model memory stores, and related derived representations of Corporation data.

315.10.2 Embeddings and vector stores shall be treated as potentially sensitive derivatives and shall be governed by source rights, privacy restrictions, public authority restrictions, protected knowledge restrictions, AI-use restrictions, access controls, deletion controls, and leakage review.

315.11 Model Artifact Rights.

315.11.1 Model Artifact Rights shall govern model weights, model files, configurations, adapters, checkpoints, evaluation outputs, inference outputs, prompts, system instructions where protectable or confidential, retrieval indexes, and related model materials.

315.11.2 Model Artifact Rights shall be reviewed before release, transfer, fine-tuning, integration, publication, benchmarking, or public-good asset incorporation.

315.12 Fine-Tuned Model Rights.

315.12.1 Fine-Tuned Model Rights shall govern models adapted using Corporation data, third-party data, public authority data, protected knowledge, research data, or other source material.

315.12.2 Fine-tuned models shall be reviewed for underlying model terms, training data rights, output rights, deletion or unlearning limitations, source restrictions, confidentiality, privacy, protected knowledge, export-control, sanctions, public-safe release, and correction.

315.13 Prompt, Evaluation, Benchmark, and Harness Rights.

315.13.1 Prompt, evaluation, benchmark, and harness rights shall govern prompt libraries, system prompts, evaluation sets, test harnesses, Gold Vectors, negative tests, benchmark libraries, scoring methods, red-team cases, validation scripts, and related evaluation materials.

315.13.2 Such materials may require restriction to prevent gaming, leakage, spoofing, misuse, protected knowledge exposure, cyber exposure, or invalid benchmark claims.

315.14 Schema, API, SDK, and Interface Rights.

315.14.1 Schema, API, SDK, and Interface Rights shall govern technical specifications, interface definitions, code libraries, implementation tools, validation tools, documentation, and compatibility materials.

315.14.2 Rights treatment shall preserve public-good interoperability while preventing false claims of certification, recognition, finance-readiness, procurement approval, provider qualification, or public authority adoption.

315.15 Dashboard, Visualization, and Map Rights.

315.15.1 Dashboard, visualization, and map rights shall govern visual outputs, geospatial layers, dashboard designs, map tiles, analytics displays, charts, legends, icons, indicators, and underlying data rights.

315.15.2 Such rights shall be reviewed for third-party mapping terms, geospatial data licenses, public authority restrictions, protected knowledge, sensitive-location exposure, privacy, and public-safe publication.

315.16 Technical Baseline Rights.

315.16.1 Technical Baseline Rights shall govern open technical baselines, reference architectures, technical profiles, controlled vocabularies, schemas, public-safe language, documentation, and related reference materials.

315.16.2 Technical Baseline Rights shall preserve open public-good use where appropriate while preventing private enclosure, unauthorized certification claims, procurement misuse, provider preference, public authority overclaim, and finance-readiness overclaim.

315.17 Standards-Support Rights.

315.17.1 Standards-Support Rights shall govern contributions to, references from, compatibility with, or support for standards, protocols, public-good frameworks, technical committees, public authority learning materials, and Nexus Standards-related materials.

315.17.2 Standards-support activity shall not imply that the Corporation is a formal standards body, certification body, regulator, procurement authority, or public authority unless separately authorized and accurately described.

315.18 Defensive Publication.

315.18.1 The Corporation may use defensive publication to place public-good technical ideas, methods, reference architectures, schemas, baselines, software patterns, or governance structures into the public domain or public record to prevent private capture or patent enclosure where lawful and mission-aligned.

315.18.2 Defensive publication shall be reviewed for confidentiality, protected knowledge, public authority restrictions, cyber sensitivity, infrastructure sensitivity, controlled technology, export-control, sanctions, IP rights, public-safe status, and publication integrity before release.

315.19 Public-Good Licensing Strategy.

315.19.1 The Corporation shall maintain a public-good licensing strategy for Public-Good Technical Assets, including software, documentation, data, schemas, baselines, evaluation assets, and publications.

315.19.2 Licensing strategy may use permissive licenses, copyleft licenses, documentation licenses, data licenses, community licenses, restricted licenses, internal licenses, non-commercial or public-benefit restrictions where appropriate, contributor license agreements, assignments, or defensive publication.

315.19.3 Licensing choices shall be made to preserve public-benefit use, interoperability, anti-enclosure, sustainability, correctionability, contributor clarity, provider neutrality, public authority trust, protected knowledge safeguards, and legal compliance.

315.20 Rights Register and Records.

315.20.1 The Corporation shall maintain a Rights Register or equivalent records for material Public-Good Technical Assets and IP-sensitive materials, including copyright records, patent records, trademark and mark records, trade secret records, database rights records, data rights records, dataset rights records, synthetic data rights records, derived data rights records, embedding and vector store rights records, model artifact rights records, fine-tuned model rights records, prompt / evaluation / benchmark / harness rights records, schema / API / SDK / interface rights records, dashboard / visualization / map rights records, technical baseline rights records, standards-support rights records, defensive publication records, licensing strategy records, permissions, licenses, restrictions, disputes, corrections, withdrawals, and archive records.

---

Section 316. Contributor Terms, Contributor License Agreements, Assignments, Moral Rights, Attribution, and Maintainer Duties

316.1 Contributor Terms Requirement.

316.1.1 The Corporation shall maintain contributor terms, repository terms, contributor license agreements, assignment instruments, developer certificates of origin, volunteer agreements, contractor agreements, fellowship terms, maintainer rules, or equivalent records sufficient to govern contributions to Public-Good Technical Assets.

316.1.2 Contributor terms shall address authority to contribute, IP rights, license rights, assignment where required, attribution, moral rights where applicable, confidentiality, data rights, AI-use restrictions, export-control, sanctions, controlled technology, public-safe claims, protected knowledge, security, repository conduct, correction, withdrawal, and enforcement.

316.1.3 No contribution shall be accepted into a material Corporation-controlled asset unless the Corporation has rights sufficient for intended use, modification, publication, licensing, correction, supersession, withdrawal, deprecation, retirement, and archive.

316.2 Contributor Eligibility.

316.2.1 Contributor eligibility may be established by role, agreement, repository access, identity verification, affiliation disclosure, training, conflict review, export-control or sanctions screening where applicable, confidentiality commitment, and acceptance of contributor terms.

316.2.2 The Corporation may limit, suspend, or deny contributor eligibility where rights are unclear, security risk exists, sanctions or export-control concerns exist, protected knowledge is implicated, conflict risk is unmanaged, conduct is unsafe, or contribution would impair public-good stewardship.

316.3 Contributor Intake.

316.3.1 Contributor intake shall identify the contributor, contribution type, repository or asset, rights instrument, license status, affiliation, conflict disclosure, confidentiality needs, data handling implications, AI-use implications, security implications, and public-safe implications where material.

316.3.2 Intake may be simplified for low-risk public contributions but shall be heightened for code, datasets, models, controlled technology, public authority materials, protected knowledge, security-sensitive materials, or contributions to high-reliance assets.

316.4 Contributor Identity and Affiliation.

316.4.1 Contributors shall provide accurate identity or contributor identity information sufficient for the contribution context, repository rules, license requirements, security review, attribution, conflict review, and legal records.

316.4.2 Contributors shall disclose material affiliation with providers, sponsors, vendors, public authorities, national companies, Project SPVs, capital actors, universities, laboratories, community bodies, or other institutions where such affiliation may affect interpretation, conflict, rights, public-safe claims, or provider neutrality.

316.4.3 Anonymous or pseudonymous contributions may be permitted only where lawful, safe, consistent with repository rules, and not inconsistent with security, attribution, export-control, sanctions, or rights requirements.

316.5 Contributor Conflict Disclosure.

316.5.1 Contributors shall disclose material conflicts that could affect the contribution, including provider interests, sponsor interests, vendor interests, public authority interests, procurement interests, investment interests, employment interests, research conflicts, IP conflicts, related-party interests, and competitive interests.

316.5.2 Conflict management may include disclosure, review limitation, recusal from approval, independent review, contribution restriction, public-safe limitation, or rejection of the contribution.

316.6 Contributor License Agreement.

316.6.1 A Contributor License Agreement may be required for contributions to software, documentation, schemas, baselines, datasets, model cards, system cards, benchmark cards, evaluation harnesses, or other material assets.

316.6.2 A Contributor License Agreement may grant the Corporation rights to use, reproduce, modify, distribute, sublicense where appropriate, publish, relicense where agreed, correct, supersede, withdraw, deprecate, retire, and archive the contribution.

316.6.3 Contributor License Agreements shall preserve contributor representations regarding authorship, authority, originality or authorized reuse, license compliance, absence of knowingly infringing material, absence of prohibited confidential material, absence of unauthorized public authority data, absence of protected knowledge unless authorized, and compliance with export-control and sanctions requirements.

316.7 Assignment Instrument Where Required.

316.7.1 Assignment instruments may be required where the Corporation must own the contribution to steward, release, enforce, defend, correct, license, or preserve the asset for public-good purposes.

316.7.2 Assignments shall be in writing where required and shall identify assigned rights, effective date, covered works, consideration where applicable, moral rights treatment where lawful, cooperation obligations, and retained rights if any.

316.7.3 Assignment shall not authorize use of materials that the assignor did not have the right to assign.

316.8 Moral Rights Treatment Where Applicable.

316.8.1 Moral rights, including rights of attribution, integrity, disclosure, withdrawal, or similar rights under applicable law, shall be addressed where relevant to contributions, commissioned works, international contributors, documentation, visual works, research outputs, maps, dashboards, diagrams, publications, and technical assets.

316.8.2 The Corporation may require waiver, consent, non-assertion, or other treatment of moral rights to the extent lawful and necessary to modify, correct, translate, publish, withdraw, supersede, deprecate, archive, or maintain public-good technical assets.

316.8.3 Moral rights treatment shall be respectful and shall not excuse misattribution, plagiarism, protected knowledge misuse, or deceptive alteration.

316.9 Attribution Rules.

316.9.1 Attribution rules shall identify when and how contributors, authors, maintainers, reviewers, sponsors, funders, data sources, public authority sources, community sources, Tribal or Indigenous sources, software dependencies, datasets, models, and third-party materials are credited.

316.9.2 Attribution shall be accurate, lawful, public-safe, license-compliant, conflict-aware, and respectful of non-attribution, confidentiality, protected knowledge, safety, privacy, and community restrictions.

316.9.3 Attribution shall not imply endorsement, approval, certification, recognition, finance-readiness, procurement approval, public authority adoption, provider preference, or responsibility beyond the attributed contribution.

316.10 Maintainer Duties.

316.10.1 Maintainers shall steward assigned assets consistent with public-benefit purpose, repository governance, secure development, license compliance, public-safe publication, provider neutrality, sponsor non-control, public authority boundary discipline, protected knowledge safeguards, and correctionability.

316.10.2 Maintainer duties may include issue triage, pull request review, contributor review, dependency review, vulnerability escalation, documentation maintenance, release preparation, changelog maintenance, correction coordination, deprecation, retirement, and archive coordination.

316.10.3 Maintainers shall not use their role to insert sponsor preference, provider preference, procurement advantage, finance-facing signals, certification-like language, recognition-like language, public authority overclaim, or unsupported technical claims.

316.11 Code Owner Duties.

316.11.1 Code Owners shall review changes within their assigned scope for correctness, security, maintainability, license compliance, dependency risk, public-safe documentation, data handling, AI-use implications, and compatibility with asset scope.

316.11.2 Code Owner approval shall not substitute for required legal review, public-safe review, data review, AI review, cyber review, protected knowledge review, release approval, or Board or officer approval where required.

316.12 Reviewer Duties.

316.12.1 Reviewers shall review contributions according to competence, assigned scope, conflict status, evidence, documentation, test results, security implications, data rights, license rights, public-safe status, and correction needs.

316.12.2 Reviewers shall reject or escalate contributions that include secrets, credentials, unauthorized data, protected knowledge, public authority restricted material, controlled technology concerns, license conflicts, security vulnerabilities, unsupported claims, or misleading boundary language.

316.13 Secure Development Duties.

316.13.1 Contributors, maintainers, Code Owners, and reviewers shall comply with secure development duties, including secure coding, dependency review, secret protection, vulnerability reporting, branch protection where applicable, release controls, artifact provenance, and incident reporting.

316.13.2 No person shall knowingly introduce malware, backdoors, malicious dependencies, secrets, credential exposures, insecure configurations, data exfiltration code, prompt injection vectors, benchmark gaming, or hidden telemetry inconsistent with policy.

316.14 Confidentiality Duties.

316.14.1 Contributors, maintainers, Code Owners, and reviewers shall protect confidential, internal, restricted, privileged, public authority, cyber-sensitive, infrastructure-sensitive, health-sensitive, finance-sensitive, commercially sensitive, research-sensitive, community-protected, and protected knowledge materials.

316.14.2 Confidential materials shall not be placed into public repositories, public issues, public pull requests, public documentation, unapproved AI tools, external communication channels, or public release artifacts.

316.15 Data / AI / Cyber Duties.

316.15.1 Contributors, maintainers, Code Owners, and reviewers shall comply with data governance, AI governance, cybersecurity, privacy, controlled-room, verifiable compute, verifiable intelligence, and public-safe publication controls applicable to their contributions.

316.15.2 Contributions involving datasets, model outputs, embeddings, AI-generated code, AI-generated documentation, inference records, compute workloads, cyber telemetry, public authority data, protected knowledge, dashboards, maps, or technical baselines shall receive applicable review before acceptance or release.

316.16 Export-Control, Sanctions, and Controlled Technology Duties.

316.16.1 Contributors, maintainers, Code Owners, reviewers, and repository participants shall comply with export-control, sanctions, controlled technology, restricted-party, restricted-jurisdiction, prohibited-end-use, and national security-sensitive restrictions where applicable.

316.16.2 Contributions involving encryption, cybersecurity tools, AI-RAN / O-RAN materials, telecom methods, geospatial systems, robotics, drones, semiconductors, advanced manufacturing, digital twins, controlled datasets, or other potentially controlled technology shall be escalated for review where required.

316.17 Public-Safe Claims Duties.

316.17.1 Contributors, maintainers, Code Owners, and reviewers shall ensure that documentation, release notes, issue comments, public repository descriptions, dashboards, maps, examples, tutorials, benchmark results, model cards, system cards, dataset cards, and technical baselines do not contain unsupported or misleading public-safe claims.

316.17.2 Public-facing technical materials shall not state or imply certification, recognition, finance-readiness, insurance-readiness, procurement approval, provider preference, public authority adoption, legal compliance approval, public warning, emergency command, rating, or guarantee unless separately authorized and accurately described.

316.18 No Contributor or Maintainer Authority to Change Institutional Meaning Without Authorization.

316.18.1 No contributor, maintainer, Code Owner, reviewer, repository participant, fellow, advisor, volunteer, contractor, sponsor, provider, public authority participant, national company participant, Project SPV participant, or technical collaborator shall have authority by contribution, repository access, issue participation, pull request approval, commit rights, release involvement, documentation drafting, or technical expertise to change the Corporation’s institutional meaning, legal role, public authority boundary, finance boundary, certification boundary, recognition boundary, procurement neutrality, provider-neutrality posture, public-safe claims, or Nexus role without competent authorization.

316.18.2 Unauthorized institutional meaning changes shall be corrected, restricted, withdrawn, or publicly or controlledly clarified where necessary.

316.19 Contributor and Maintainer Records.

316.19.1 The Corporation shall maintain Contributor and Maintainer Records, including contributor terms, eligibility records, intake records, identity and affiliation records, conflict disclosures, contributor license agreements, assignment instruments, moral rights records, attribution records, maintainer assignments, Code Owner records, reviewer records, secure development duty records, confidentiality duty records, data / AI / cyber duty records, export-control / sanctions / controlled technology review records, public-safe claims review records, institutional-meaning authorization records, corrections, rejected contributions, reverted contributions, withdrawals, suspensions, terminations, and archive records.

Section 317. Open Licensing, Public-Good Licensing, Restricted Licensing, Dual Licensing, and License Selection

317.1 Licensing Purpose.

317.1.1 Licensing shall be used by the Corporation as a mission-critical governance instrument to preserve public-good access, interoperability, technical memory, anti-enclosure, lawful reuse, attribution, correctionability, security, privacy, protected knowledge safeguards, public authority boundary discipline, provider neutrality, sponsor non-control, and durable stewardship of Public-Good Technical Assets.

317.1.2 Licensing decisions shall be made according to asset class, intended audience, public-benefit purpose, data sensitivity, security risk, public-safe status, intellectual property rights, contributor rights, third-party dependencies, public authority restrictions, grant terms, donor terms, sponsor terms, contract terms, data rights, AI-use restrictions, privacy obligations, cyber sensitivity, infrastructure sensitivity, export-control, sanctions, protected knowledge, community safeguards, sustainability, and correction obligations.

317.1.3 Licensing shall not be used to imply certification, recognition, finance-readiness, procurement approval, public authority adoption, legal compliance approval, provider preference, public warning, emergency command, rating, guarantee, or execution authority.

317.2 Open-Source Licensing.

317.2.1 Open-source licensing may be used for software, code libraries, reference implementations, validation tools, SDKs, APIs, scripts, repository templates, public-good software, and related technical assets where open release is lawful, public-safe, mission-aligned, security-reviewed, license-compatible, and rights-supported.

317.2.2 Open-source licensing shall be selected to advance public-good reuse, transparency, interoperability, auditability, contributor clarity, technical memory, and anti-enclosure while preserving necessary protections against misuse, false endorsement, unsafe reliance, protected knowledge exposure, and private capture.

317.2.3 Open-source release shall not include confidential materials, public authority restricted materials, personal information, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, controlled technology, protected knowledge, secrets, keys, tokens, credentials, unreviewed vulnerability details, or other restricted materials unless lawful, public-safe, and approved through competent review.

317.3 Open Data Licensing.

317.3.1 Open data licensing may be used for datasets, metadata, public-safe evidence summaries, public-safe observability data, public-good reference data, schema-aligned sample data, public-safe benchmark data, and other data assets approved for public release.

317.3.2 Open data licensing shall address attribution, redistribution, derivative use, commercial use where applicable, AI-use rights, no-endorsement language, correction obligations, source limitations, public-safe limitations, and restrictions against misleading reliance.

317.3.3 Data shall not be licensed as open data merely because it is publicly accessible, technically downloadable, non-confidential in appearance, aggregated, de-identified, synthetic, derived, or held in a public repository. Open data licensing shall require rights review, privacy review, public-safe review, protected knowledge review where applicable, public authority review where applicable, and correction path.

317.4 Public-Good Licensing.

317.4.1 Public-good licensing may be used where the Corporation seeks to make an asset available for broad public-benefit use while preserving mission-aligned safeguards, attribution, anti-enclosure objectives, non-endorsement, non-certification, non-recognition, non-finance-readiness, non-procurement, non-public-authority, and correction language.

317.4.2 Public-good licenses may include open-source licenses, open data licenses, documentation licenses, public-benefit use terms, community licenses, standards-support licenses, research-use licenses, non-commercial licenses where appropriate, controlled-access licenses, or hybrid structures.

317.4.3 Public-good licensing shall not be used to disguise private benefit, sponsor control, provider preference, commercialization of protected knowledge, unauthorized public authority data use, or unreviewed release of sensitive technical materials.

317.5 Research Licensing.

317.5.1 Research licensing may be used for research datasets, methods, evaluation materials, technical notes, models, documentation, evidence templates, and public-good technical assets made available for research, validation, peer review, academic use, public authority learning, or controlled collaboration.

317.5.2 Research licenses may restrict commercial use, redistribution, AI training, public release, publication, attribution, derivative works, external sharing, re-identification, reverse engineering, or use beyond approved research purposes where necessary.

317.5.3 Research licensing shall preserve publication integrity, correctionability, participant protection, privacy, public authority restrictions, protected knowledge safeguards, and public-safe claims discipline.

317.6 Standards-Support Licensing.

317.6.1 Standards-support licensing may be used for schemas, profiles, APIs, SDKs, reference architectures, technical baselines, ontologies, controlled vocabularies, data dictionaries, interoperability interfaces, conformance-support materials, and technical specifications intended to support common understanding or interoperability.

317.6.2 Standards-support licensing shall preserve accessibility, implementability, attribution, version control, correction, interoperability, and anti-enclosure while avoiding unsupported claims of formal standard status, certification, procurement mandate, public authority adoption, finance-readiness, or recognition.

317.6.3 Where standards-support materials may interface with Nexus Standards, public authorities, industry bodies, universities, providers, or consortiums, license terms shall preserve role separation, non-execution, public-good stewardship, and provider neutrality.

317.7 Restricted Licensing.

317.7.1 Restricted licensing may be used for assets that are not appropriate for open release due to confidentiality, public authority restrictions, privacy, health sensitivity, cyber sensitivity, infrastructure sensitivity, protected knowledge, controlled technology, export-control, sanctions, grant restrictions, contract restrictions, license conflicts, security risks, or public-safe concerns.

317.7.2 Restricted licenses may limit access, users, purpose, duration, geography, systems, AI use, redistribution, derivative works, publication, reverse engineering, commercial use, public authority use, finance-facing use, provider use, sponsor use, or external sharing.

317.7.3 Restricted licensing shall be recorded and shall include access controls, use limitations, confidentiality terms, correction rights, termination rights, return or deletion obligations, and incident notification requirements where appropriate.

317.8 Dual Licensing Where Appropriate.

317.8.1 Dual licensing may be used where different rights structures are necessary for public-good release, restricted institutional use, commercial sustainability, public authority use, research collaboration, or controlled enterprise interface, provided that dual licensing remains mission-aligned and legally supported.

317.8.2 Dual licensing shall not create hidden provider preference, sponsor advantage, private enclosure, discriminatory access, public authority confusion, procurement advantage, finance-readiness implication, or inconsistency with contributor rights or third-party license terms.

317.8.3 Dual licensing shall identify which license applies to which asset, version, audience, use case, repository, data class, jurisdiction, release channel, and correction status.

317.9 Permissive License Considerations.

317.9.1 Permissive licenses may be preferred where the Corporation seeks broad implementation, low-friction reuse, interoperability, public authority learning, academic use, provider-neutral adoption, public-good experimentation, or ecosystem diffusion.

317.9.2 Before selecting a permissive license, the Corporation shall consider risk of private enclosure, loss of reciprocal public-good contribution, false endorsement, misuse in certification-like claims, provider capture, public authority overclaim, security-sensitive reuse, and inadequate correction visibility.

317.9.3 Permissive licensing shall include non-endorsement and limitation language where necessary to prevent misleading reliance.

317.10 Copyleft License Considerations.

317.10.1 Copyleft licenses may be considered where reciprocal openness, anti-enclosure, derivative-work sharing, public-good continuity, and ecosystem accountability are important.

317.10.2 Before selecting a copyleft license, the Corporation shall assess compatibility with dependencies, contributor rights, public authority use, university use, government use, commercial implementation, SDK or API use, standards-support use, and the intended public-good adoption pathway.

317.10.3 Copyleft licensing shall not be selected where it would unintentionally prevent public-benefit adoption, conflict with grant or public authority requirements, impair interoperability, or violate third-party license terms.

317.11 Community License Considerations.

317.11.1 Community licenses may be considered where assets involve community-protected data, local knowledge, Indigenous knowledge, protected knowledge, public-safe mapping, culturally sensitive materials, environmental knowledge, or community-governed use conditions.

317.11.2 Community license considerations shall address consent, non-consent, attribution, non-attribution, withdrawal, restriction, non-commercial use, benefit-sharing where appropriate, AI-use restrictions, mapping restrictions, publication restrictions, and grievance pathways.

317.11.3 Community licensing shall not be used as a substitute for lawful authority, Tribal / Indigenous protocol permission where applicable, protected knowledge safeguards, or community review where required.

317.12 Government, University, and Public Authority License Considerations.

317.12.1 Licenses involving government, university, public authority, public-sector, or academic users shall be reviewed for sovereign immunity concerns where applicable, public records implications, procurement rules, grant rules, academic publication rights, research integrity, open access expectations, data-sharing restrictions, public authority data restrictions, and public-safe publication language.

317.12.2 Government or public authority use of a licensed asset shall not imply public authority adoption, official guidance, procurement approval, public finance approval, public warning, emergency command, recognition, certification, or execution authority unless separately and lawfully established by the relevant authority.

317.12.3 University and laboratory licensing shall preserve publication integrity, attribution, student and researcher rights where applicable, IP clarity, confidentiality, data rights, export-control review, and correctionability.

317.13 Commercial Use License Considerations.

317.13.1 Commercial use licensing shall be reviewed where a Public-Good Technical Asset may be used by vendors, providers, sponsors, national companies, Project SPVs, enterprise actors, consultants, platforms, or other commercial entities.

317.13.2 Commercial use license considerations shall include public-good mission alignment, anti-enclosure, provider neutrality, sponsor non-control, false endorsement risk, procurement misuse risk, certification misuse risk, finance-readiness misuse risk, public authority confusion, protected knowledge, data rights, revenue treatment where applicable, and correction obligations.

317.13.3 Commercial use shall not be permitted to distort asset meaning, remove limitation language, obscure attribution, privatize public-good baselines, or imply Corporation approval of products, services, providers, projects, or investments.

317.14 Data License Considerations.

317.14.1 Data license selection shall consider data source, data rights, privacy, sensitive data classification, public authority restrictions, protected knowledge restrictions, AI-use permissions, redistribution, derivative data, re-identification risk, commercial use, attribution, correction, retention, deletion, and public-safe status.

317.14.2 Data licenses shall distinguish rights to use data from rights to use copyrightable expression, database structure, confidential information, model outputs, personal information, public authority restricted data, and protected knowledge.

317.15 Model License Considerations.

317.15.1 Model license selection shall consider model weights, model artifacts, fine-tuned models, adapters, prompts, system instructions, evaluation outputs, inference outputs, embeddings, retrieval indexes, source data rights, provider terms, AI-use restrictions, output rights, safety restrictions, export-control, sanctions, and public-safe release.

317.15.2 Model licenses shall prohibit or restrict uses inconsistent with the Corporation’s non-executing role, including public authority decisions, public warnings, emergency commands, certification, recognition, finance-readiness, procurement approval, provider ranking, clinical advice, legal advice, or regulated professional outputs.

317.16 Documentation License Considerations.

317.16.1 Documentation license selection shall apply to manuals, user guides, technical baselines, reference architectures, profiles, schemas, diagrams, screenshots, tutorials, release notes, public authority learning materials, model cards, system cards, benchmark cards, dataset cards, and public-safe guidance.

317.16.2 Documentation licenses shall address attribution, redistribution, modification, translation, derivative works, public-safe limitation retention, non-endorsement, versioning, correction notices, and withdrawal.

317.16.3 Documentation shall not be licensed for reuse where reuse would remove limitation language, create unsafe reliance, expose protected knowledge, violate public authority restrictions, or misstate institutional authority.

317.17 License Compatibility Review.

317.17.1 License Compatibility Review shall be required before combining, distributing, releasing, sublicensing, relicensing, incorporating, embedding, packaging, publishing, or deriving assets from materials subject to different license terms.

317.17.2 License Compatibility Review shall assess open-source dependencies, copyleft obligations, attribution requirements, patent clauses, trademark restrictions, data licenses, model licenses, documentation licenses, community licenses, government licenses, university licenses, public authority terms, and third-party proprietary restrictions.

317.17.3 License conflicts shall be resolved by replacement, exclusion, permission, re-scoping, separate distribution, restricted release, legal review, or refusal of release.

317.18 Grant, Donor, Sponsor, Contract, Public Authority, Data, AI, Cyber, Privacy, Export-Control, and Protected Knowledge Restrictions.

317.18.1 License selection and release shall comply with applicable grant, donor, sponsor, contract, public authority, data-sharing, contributor, AI, cyber, privacy, export-control, sanctions, controlled technology, community, Tribal / Indigenous, and protected knowledge restrictions.

317.18.2 No license shall authorize use, publication, transfer, AI training, redistribution, commercial use, derivative work, mapping, or public authority use that the Corporation lacks authority to permit.

317.18.3 Where restrictions conflict with open release, the Corporation shall restrict, delay, redact, segment, re-scope, deny release, or seek additional permission.

317.19 License Approval.

317.19.1 License approval for material Public-Good Technical Assets shall be granted by competent authority under Board-approved policy, officer delegation, legal review where required, technical governance mandate, or other recorded authorization.

317.19.2 License approval shall identify the asset, version, rights basis, selected license, release scope, audience, restrictions, public-safe status, dependency status, contributor rights, third-party rights, data rights, AI-use status, correction path, and review date where appropriate.

317.19.3 License approval shall be obtained before public release, public repository publication, public documentation release, external distribution, sublicensing, relicensing, dual licensing, or materially changing license terms.

317.20 License Records.

317.20.1 The Corporation shall maintain License Records, including licensing purpose records, open-source license records, open data license records, public-good license records, research license records, standards-support license records, restricted license records, dual license records, permissive license considerations, copyleft license considerations, community license considerations, government / university / public authority license considerations, commercial use license considerations, data license considerations, model license considerations, documentation license considerations, license compatibility reviews, restriction reviews, license approvals, license changes, notices, attributions, exceptions, disputes, corrections, withdrawals, deprecations, retirements, and archive records.

---

Section 318. Restricted Assets and Non-Public Technical Materials

318.1 Restricted Asset Purpose.

318.1.1 Restricted Assets and Non-Public Technical Materials shall be governed to protect sensitive technical, legal, operational, public authority, health, rights-bearing, cyber, infrastructure, community, protected knowledge, commercial, financial, repository, security, and controlled technology interests from unauthorized access, misuse, disclosure, publication, AI processing, transfer, extraction, or unsafe reliance.

318.1.2 Restricted status may apply to software, repositories, datasets, models, prompts, embeddings, evaluation assets, threat models, red-team outputs, vulnerabilities, schemas, APIs, SDKs, technical baselines, reference architectures, dashboards, maps, proof receipts, public authority materials, controlled-room exhibits, and documentation.

318.1.3 Restriction shall be based on substance, risk, law, contract, public-safe status, and safeguards, not on whether the material is complete, draft, internal, technical, non-obvious, already circulated to a limited audience, or stored in a platform that allows sharing.

318.2 Sensitive Infrastructure Materials.

318.2.1 Sensitive Infrastructure Materials include technical, geospatial, operational, dependency, vulnerability, configuration, resilience, outage, recovery, degraded-mode, or security materials relating to critical infrastructure, utilities, telecom, energy, water, food, ports, transportation, public works, health systems, emergency systems, AI-RAN / O-RAN systems, cyber-physical systems, industrial systems, satellite systems, digital twins, or other mission-critical systems.

318.2.2 Such materials shall be restricted where disclosure may enable harm, expose vulnerabilities, reveal dependency, support targeting, create public authority confusion, create insurance or finance sensitivity, or compromise public-safe publication.

318.3 Cybersecurity-Sensitive Materials.

318.3.1 Cybersecurity-Sensitive Materials include vulnerability details, exploit-relevant information, threat models, penetration-test outputs, red-team findings, incident logs, credentials, keys, tokens, secrets, security architecture, detection rules, access logs, repository logs, cloud configurations, security weaknesses, and remediation plans.

318.3.2 Such materials shall be restricted, access-controlled, and released only through public-safe, coordinated, or need-to-know processes approved by competent authority.

318.4 Controlled Technology Materials.

318.4.1 Controlled Technology Materials include technical data, software, models, designs, specifications, encryption materials, cybersecurity tools, telecom methods, AI-RAN / O-RAN materials, DePIN or DLT materials, robotics, drones, geospatial systems, digital twins, advanced manufacturing information, semiconductor information, industrial control systems, and other materials that may require controlled-technology review.

318.4.2 Controlled Technology Materials shall be reviewed for export-control, sanctions, national security sensitivity, public authority restrictions, license obligations, contributor eligibility where lawful and required, access controls, and public-safe release.

318.5 Export-Controlled Materials.

318.5.1 Export-Controlled Materials shall be held, restricted, licensed where required, denied for release, localized, segmented, or otherwise controlled according to applicable export-control and sanctions obligations.

318.5.2 No Export-Controlled Material shall be published, transferred, shared with foreign persons where restricted, processed in unapproved jurisdictions, released through public repositories, or entered into AI systems without required review and authorization.

318.6 Public Authority Materials.

318.6.1 Public Authority Materials include records, data, communications, presentations, briefings, learning materials, controlled-room materials, public records materials, confidential agency materials, emergency-management materials, procurement-related materials, grant-related materials, regulatory materials, public finance materials, public health materials, public safety materials, and public works materials involving public authorities.

318.6.2 Public Authority Materials shall be governed by capacity records, lawful authority, permitted use, confidentiality, public records review where applicable, procurement and grant sensitivity, public-safe publication, official-status limitations, and correction path.

318.7 Health-Sensitive Materials.

318.7.1 Health-Sensitive Materials include health, public health, clinical, medical, behavioral health, disability-related, epidemiological, youth, vulnerable-population, health-system, emergency medical, biosecurity, or health-adjacent materials.

318.7.2 Such materials shall be restricted where privacy, ethics, public authority restrictions, re-identification risk, stigmatization, public-safe publication, biosecurity misuse, or vulnerable-population harm may arise.

318.8 Rights-Bearing Data Materials.

318.8.1 Rights-Bearing Data Materials include materials that may affect rights, dignity, access, participation, reputation, benefits, civil rights, protected status, accessibility, vulnerability, safety, or opportunity of persons or communities.

318.8.2 Such materials shall be restricted where disclosure, AI processing, mapping, classification, profiling, publication, or external transfer could cause harm, discrimination, retaliation, exclusion, or misleading public interpretation.

318.9 Community-Protected Materials.

318.9.1 Community-Protected Materials include data, observations, maps, narratives, grievance records, vulnerability information, public health concerns, environmental information, local resilience knowledge, and other materials provided by or relating to communities under explicit or implicit trust, restriction, or safeguards expectations.

318.9.2 Such materials shall be restricted to prevent extraction, stigmatization, retaliation, exposure, decontextualization, sponsor misuse, provider misuse, public authority misuse, or unsafe public mapping.

318.10 Tribal / Indigenous, Local, Territorial, Cultural, Environmental, and Protected Knowledge Materials.

318.10.1 Tribal / Indigenous, local, territorial, cultural, environmental, sacred, ecological, land-based, vulnerability-related, and Protected Knowledge Materials shall be treated as restricted unless competent record determines that release is lawful, respectful, permissioned, public-safe, and consistent with applicable protocols.

318.10.2 Such materials shall not be released, mapped, translated, generalized, embedded, trained on, summarized, commercialized, transferred, or externally shared without protected knowledge review and appropriate authority.

318.11 Commercially Sensitive Materials.

318.11.1 Commercially Sensitive Materials include vendor documentation, provider data, product roadmaps, pricing, trade secrets, confidential technical materials, proprietary datasets, supplier information, procurement-sensitive materials, customer data, and non-public collaboration materials.

318.11.2 Such materials shall be restricted according to contract, confidentiality, IP, competition, procurement neutrality, provider neutrality, and public-safe publication controls.

318.12 Finance-Sensitive Materials.

318.12.1 Finance-Sensitive Materials include non-public budgets, donor data, sponsor data, funder terms, restricted-fund information, bank information, payment information, capital-reader materials, finance-readiness-facing inputs, insurance-sensitive materials, underwriting-relevant materials, and public finance-sensitive materials.

318.12.2 Such materials shall be restricted to prevent unauthorized disclosure, investment advice implications, rating implications, finance-readiness overclaim, public finance overclaim, conflicts, and misuse by capital actors.

318.13 Security-Sensitive Repository Materials.

318.13.1 Security-Sensitive Repository Materials include private code, secret scanning results, dependency vulnerability reports, build logs, deployment scripts, internal configuration files, repository access logs, security advisories, branch protection settings, release keys, and sensitive issue threads.

318.13.2 Such materials shall be protected through restricted repository access, least privilege, logging, branch protection, secret management, coordinated disclosure, and public-safe release review.

318.14 Non-Public Test Harnesses, Threat Models, Red-Team Outputs, Exploit-Relevant Materials, and Vulnerability Details.

318.14.1 Non-public test harnesses, threat models, red-team outputs, exploit-relevant materials, vulnerability details, adversarial prompts, benchmark answer keys, Gold Vectors where sensitive, negative tests where sensitive, prompt-injection cases, and data-poisoning examples shall be restricted where release may enable gaming, exploitation, evasion, unsafe replication, or invalidation of evaluation methods.

318.14.2 Such materials may be shared only under need-to-know, controlled-room, coordinated disclosure, restricted license, or other approved access conditions.

318.15 Restricted Access Controls.

318.15.1 Restricted Assets shall be protected through access controls appropriate to sensitivity, including identity verification, least privilege, need-to-know access, role-based or attribute-based access, multi-factor authentication, logging, monitoring, encryption where appropriate, no-download controls, controlled-room access, repository restrictions, and periodic access review.

318.15.2 Restricted access shall not be granted because of sponsor status, provider status, donor status, public authority proximity, Board status without need, contributor interest, commercial opportunity, or reputational benefit.

318.16 Controlled-Room Release Controls.

318.16.1 Restricted Assets may be released or reviewed through controlled rooms, clean rooms, data rooms, evidence rooms, public authority rooms, no-download rooms, restricted repositories, or compute-to-data environments where broader release is unsafe or unauthorized.

318.16.2 Controlled-room release shall be governed by room charter, participant screening, capacity classification, conflict review, public authority boundary review, finance boundary review, data / AI / cyber / privacy review, protected knowledge review, logging, output review, and closeout.

318.17 Public-Safe Redaction.

318.17.1 Public-safe redaction may be used to remove, obscure, aggregate, mask, generalize, delay, segment, or summarize restricted details while preserving accurate public meaning.

318.17.2 Redaction shall not create misleading public-safe summaries, false certainty, false absence of risk, false public authority meaning, false finance-readiness, false certification, false recognition, false procurement approval, or false provider neutrality.

318.17.3 Redaction records shall identify the basis for redaction, scope, authority, public-safe rationale, and correction path.

318.18 Restricted Asset Release Denial, Delay, Redaction, Segmentation, or Re-Scoping.

318.18.1 The Corporation shall deny, delay, redact, segment, re-scope, restrict, aggregate, withdraw, or refuse release of Restricted Assets where release would violate law, contract, public authority restrictions, privacy, ethics, protected knowledge obligations, export-control, sanctions, cybersecurity, infrastructure safety, public-safe publication, contributor rights, or public-benefit purpose.

318.18.2 Release denial, delay, redaction, segmentation, or re-scoping shall be recorded with reason and review path where appropriate.

318.19 Restricted Asset Records.

318.19.1 The Corporation shall maintain Restricted Asset Records, including restricted asset purpose records, sensitive infrastructure material records, cybersecurity-sensitive material records, controlled technology material records, export-controlled material records, public authority material records, health-sensitive material records, rights-bearing data material records, community-protected material records, Tribal / Indigenous / local / territorial / cultural / environmental / protected knowledge material records, commercially sensitive material records, finance-sensitive material records, security-sensitive repository material records, non-public test harness / threat model / red-team / exploit-relevant / vulnerability material records, access control records, controlled-room release records, redaction records, release denial records, delay records, segmentation records, re-scoping records, corrections, withdrawals, and archive records.

---

Section 319. Secure Development Lifecycle

319.1 Secure Development Purpose.

319.1.1 The Corporation shall maintain a Secure Development Lifecycle for material Public-Good Technical Assets to protect confidentiality, integrity, availability, public trust, public-safe publication, evidence integrity, research integrity, repository integrity, license compliance, supply-chain assurance, privacy, cybersecurity, protected knowledge, public authority data, and correctionability.

319.1.2 The Secure Development Lifecycle shall apply to public-good software, schemas, APIs, SDKs, dashboards, maps, data tools, controlled-room tools, evidence systems, AI systems, model evaluation systems, verifiable compute tools, observability tools, technical baselines, documentation, release artifacts, and related repositories.

319.1.3 Secure development shall be proportionate to risk and shall distinguish prototypes, internal tools, public releases, controlled-room tools, public authority learning tools, research tools, high-reliance assets, and restricted assets.

319.2 Secure Design Review.

319.2.1 Secure Design Review shall be conducted where material technical assets may affect sensitive data, public authority data, public-facing publication, cybersecurity, privacy, AI governance, controlled-room access, protected knowledge, critical infrastructure, or high-reliance workflows.

319.2.2 Secure Design Review shall assess architecture, trust boundaries, authentication, authorization, data flows, storage, logging, encryption where appropriate, dependency assumptions, AI integration, public-safe output controls, failure modes, recovery, and correction paths.

319.2.3 Design defects shall be corrected, mitigated, accepted by competent authority with record, or result in re-scoping before release.

319.3 Threat Modeling.

319.3.1 Threat modeling shall be conducted for material systems where misuse, unauthorized access, data exposure, prompt injection, data poisoning, supply-chain compromise, repository compromise, public-safe publication failure, or protected knowledge exposure is reasonably foreseeable.

319.3.2 Threat modeling may assess adversaries, abuse cases, trust boundaries, attack surfaces, credentials, secrets, dependency risk, AI-specific threats, data flows, public authority data, controlled-room exposure, infrastructure-sensitive materials, and public-facing interfaces.

319.3.3 Threat model findings shall be recorded and linked to mitigation, testing, release readiness, and monitoring.

319.4 Code Review.

319.4.1 Material code changes shall receive code review by competent reviewers before release, merge into protected branches, deployment, or external publication, subject to repository policy and risk classification.

319.4.2 Code Review shall assess correctness, security, data handling, privacy, AI-use implications, dependency changes, secrets exposure, license compliance, accessibility where applicable, public-safe outputs, performance where material, and maintainability.

319.4.3 Code Review shall not substitute for legal, privacy, public-safe, protected knowledge, export-control, or release approval where those reviews are required.

319.5 Peer Review.

319.5.1 Peer Review may be required for technical assets, methods, evaluation harnesses, benchmark libraries, schemas, baselines, reference architectures, dashboards, maps, AI governance tools, or high-reliance outputs where expert review materially improves quality, reliability, public-safe framing, or correctionability.

319.5.2 Peer reviewers shall be conflict-reviewed where sponsor, provider, public authority, commercial, academic, or Related Party interests could affect review.

319.5.3 Peer Review findings shall be documented, resolved, accepted with limitation, or escalated before release where material.

319.6 Dependency Review.

319.6.1 Dependency Review shall assess third-party libraries, packages, frameworks, models, datasets, APIs, tools, containers, build actions, hosted services, and other dependencies for security, license, provenance, maintenance, compatibility, transitive risk, malicious package risk, typosquatting, abandonment, vulnerability history, and provider dependency.

319.6.2 High-risk dependencies shall be replaced, pinned, sandboxed, restricted, monitored, or approved by competent authority with mitigation.

319.6.3 Dependency Review shall be repeated when dependencies materially change, vulnerabilities are identified, releases occur, or risk context changes.

319.7 License Review.

319.7.1 License Review shall assess whether assets, dependencies, datasets, models, documentation, code snippets, schemas, APIs, SDKs, images, diagrams, and other incorporated materials may lawfully be used, modified, distributed, released, sublicensed, or combined.

319.7.2 License Review shall identify attribution requirements, copyleft obligations, commercial-use restrictions, redistribution restrictions, AI-use restrictions, model restrictions, patent clauses, trademark restrictions, data restrictions, and incompatibilities.

319.7.3 License issues shall be resolved before public release or restricted release.

319.8 Vulnerability Review.

319.8.1 Vulnerability Review shall assess technical assets for known vulnerabilities, design vulnerabilities, dependency vulnerabilities, configuration weaknesses, authentication weaknesses, authorization defects, injection risks, data exposure, insecure logging, insecure defaults, prompt injection risks, data poisoning risks, insecure deserialization, insecure API patterns, and repository risks.

319.8.2 Vulnerabilities shall be classified, remediated, mitigated, accepted by competent authority with record, restricted, or cause release delay or withdrawal.

319.9 Secrets Review.

319.9.1 Secrets Review shall verify that repositories, release artifacts, documentation, examples, logs, issues, pull requests, notebooks, datasets, configuration files, containers, dashboards, maps, test harnesses, and AI prompts do not expose secrets, credentials, keys, tokens, certificates, recovery codes, connection strings, private URLs, privileged endpoints, or sensitive configuration values.

319.9.2 Suspected secret exposure shall trigger immediate containment, revocation, rotation, repository history review, downstream dependency review, and incident response where required.

319.10 Secure Configuration Review.

319.10.1 Secure Configuration Review shall assess default settings, environment variables, access controls, logging settings, deployment settings, cloud permissions, repository permissions, AI-tool permissions, API permissions, dashboard permissions, map publication settings, controlled-room settings, and public links.

319.10.2 Secure defaults shall be used where feasible, including least privilege, private-by-default where appropriate, no-training defaults where applicable, disabled public indexing for restricted assets, and restricted export for sensitive materials.

319.11 Test Coverage.

319.11.1 Material technical assets shall have test coverage proportionate to risk, including unit tests, integration tests, regression tests, validation tests, schema tests, API tests, SDK tests, dashboard tests, map tests, data quality tests, model evaluation tests, and public-safe output tests where applicable.

319.11.2 Test coverage shall focus on correctness, reliability, edge cases, failure modes, compatibility, security-relevant behavior, and correction of previously identified defects.

319.12 Negative Testing.

319.12.1 Negative testing shall assess how technical assets behave under invalid, malformed, adversarial, incomplete, stale, misclassified, unauthorized, or unexpected inputs.

319.12.2 Negative testing shall include public-safe failure modes where outputs may otherwise imply false certainty, public warning, emergency command, public authority decision, certification, recognition, finance-readiness, procurement approval, rating, or provider preference.

319.13 Security Testing.

319.13.1 Security testing may include static analysis, dependency scanning, secret scanning, dynamic testing, penetration testing, configuration testing, access-control testing, fuzz testing, container scanning, infrastructure-as-code review, repository security review, and cloud-security review.

319.13.2 Security testing shall be prioritized for assets that are public-facing, externally released, API-enabled, repository-hosted, data-processing, AI-enabled, controlled-room-related, public authority-facing, or handling sensitive materials.

319.14 Accessibility Testing Where Applicable.

319.14.1 Accessibility testing shall be conducted where technical assets include user interfaces, dashboards, maps, documentation, public authority learning materials, controlled-room interfaces, forms, publications, or public-facing tools.

319.14.2 Accessibility testing shall address assistive technology compatibility, keyboard navigation, readable structure, captions, alternative text, color-independent communication, language access where appropriate, plain-language support where appropriate, and accessible error messages.

319.15 Privacy and Data Protection Testing Where Applicable.

319.15.1 Privacy and data protection testing shall assess whether technical assets collect, store, process, transmit, log, display, export, retain, delete, or expose data consistent with data governance, privacy, consent, notice, minimization, purpose limitation, access control, and public-safe publication.

319.15.2 Testing shall include review of logs, telemetry, analytics, cookies, AI prompts, embeddings, exports, downloads, dashboards, maps, public links, and deletion workflows where applicable.

319.16 AI Safety Testing Where Applicable.

319.16.1 AI safety testing shall be conducted for AI-enabled assets, AI governance tools, retrieval systems, summarizers, classifiers, agentic systems, evaluation systems, public-safe drafting tools, anomaly detectors, and AI-assisted dashboards where applicable.

319.16.2 AI safety testing shall assess hallucination, bias, prompt injection, data leakage, retrieval errors, unsafe outputs, protected knowledge exposure, public authority overclaim, finance overclaim, certification overclaim, recognition overclaim, procurement overclaim, and correction behavior.

319.17 Public-Safe Output Testing Where Applicable.

319.17.1 Public-Safe Output Testing shall assess whether outputs, dashboards, maps, logs, receipts, reports, documentation, labels, warnings, indicators, scores, classifications, and interface messages can be misread as public warning, emergency command, public authority decision, certification, recognition, finance-readiness, procurement approval, rating, provider preference, legal compliance approval, or guarantee.

319.17.2 Where misreading risk exists, the Corporation shall redesign outputs, revise labels, add limitation language, restrict release, require review gates, or deny release.

319.18 Release Readiness Review.

319.18.1 Release Readiness Review shall be completed before material release of technical assets.

319.18.2 Release Readiness Review shall confirm scope, version, license, rights, documentation, security review, vulnerability status, dependency status, test status, accessibility status where applicable, privacy review where applicable, AI safety review where applicable, public-safe output review where applicable, protected knowledge review where applicable, export-control review where applicable, release notes, rollback plan, correction path, and release authority.

319.18.3 Assets shall not be released where unresolved defects, rights issues, vulnerabilities, public-safe concerns, protected knowledge concerns, public authority restrictions, or boundary risks make release unsafe or unauthorized.

319.19 Secure Development Records.

319.19.1 The Corporation shall maintain Secure Development Records, including secure development purpose records, secure design reviews, threat models, code reviews, peer reviews, dependency reviews, license reviews, vulnerability reviews, secrets reviews, secure configuration reviews, test coverage records, negative testing records, security testing records, accessibility testing records, privacy and data protection testing records, AI safety testing records, public-safe output testing records, release readiness reviews, release approvals, release denials, corrections, patches, withdrawals, deprecations, retirements, and archive records.

---

Section 320. Repository Governance and Access Control

320.1 Repository Governance Purpose.

320.1.1 Repository governance shall protect the integrity, security, rights, provenance, technical memory, access control, public-safe release, and correctionability of repositories used by the Corporation for software, documentation, datasets, models, schemas, APIs, SDKs, dashboards, maps, technical baselines, reference architectures, evaluation assets, test harnesses, issue tracking, release management, and related public-good technical assets.

320.1.2 Repository governance shall prevent unauthorized access, unauthorized release, secret exposure, license contamination, dependency compromise, supply-chain compromise, public authority data exposure, protected knowledge exposure, cyber-sensitive exposure, infrastructure-sensitive exposure, unsupported public claims, sponsor or provider capture, and loss of technical memory.

320.2 Repository Register.

320.2.1 The Corporation shall maintain a Repository Register identifying material repositories controlled by, maintained by, contributed to, mirrored by, archived by, or relied upon by the Corporation.

320.2.2 The Repository Register shall identify repository name, owner, maintainer, purpose, asset class, repository class, location, platform provider, access class, public-safe status, license status, security status, dependency status, vulnerability status, branch protections, release process, archive status, and correction path.

320.3 Repository Owner.

320.3.1 Each material repository shall have a Repository Owner responsible for institutional purpose, access authority, release authority within delegation, repository classification, risk posture, and alignment with the Corporation’s public-benefit purposes.

320.3.2 Repository Owner status shall not confer personal ownership, public authority authority, certification authority, recognition authority, finance-readiness authority, procurement authority, or authority to make public claims beyond recorded delegation.

320.4 Repository Maintainer.

320.4.1 Each material repository shall have one or more Repository Maintainers responsible for day-to-day repository operations, issue triage, pull request handling, branch protection, access coordination, release preparation, documentation updates, dependency updates, vulnerability escalation, and correction coordination.

320.4.2 Repository Maintainers shall follow secure development, license, data, AI, cyber, public-safe publication, protected knowledge, and records requirements.

320.5 Repository Access Classes.

320.5.1 Repositories shall be assigned access classes based on content sensitivity, public-safe status, data class, cybersecurity risk, public authority restrictions, protected knowledge, license status, export-control or controlled technology status, and release status.

320.5.2 Repository Access Classes may include public, internal, restricted, controlled, archived, sealed, cyber-restricted, public authority-restricted, protected-knowledge-restricted, controlled technology-restricted, or other approved classes.

320.5.3 Access class shall determine who may view, clone, fork, download, contribute, approve, merge, release, archive, or administer the repository.

320.6 Public Repository.

320.6.1 A Public Repository may be used for assets approved for public release, including open-source software, public documentation, open technical baselines, schemas, APIs, SDKs, public-safe reference materials, and public-good technical assets.

320.6.2 Public Repositories shall be reviewed before publication to ensure they do not contain confidential information, personal information, public authority restricted materials, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, protected knowledge, credentials, keys, tokens, secrets, unreviewed vulnerabilities, controlled technology, finance-sensitive data, or unauthorized third-party materials.

320.6.3 Public Repository descriptions, README files, issue templates, release notes, badges, examples, and documentation shall include limitation language where necessary to prevent overclaim.

320.7 Internal Repository.

320.7.1 An Internal Repository may be used for Corporation work that is not publicly released but does not require heightened restricted or controlled handling.

320.7.2 Internal Repositories shall be access-controlled, reviewed for data and confidentiality, monitored for secrets, and subject to license, dependency, vulnerability, and public-safe release review before any external release.

320.8 Restricted Repository.

320.8.1 A Restricted Repository shall be used for materials requiring heightened protection due to confidentiality, public authority restrictions, privacy, cyber sensitivity, infrastructure sensitivity, controlled technology, health sensitivity, finance sensitivity, commercial sensitivity, research sensitivity, community protection, protected knowledge, export-control, sanctions, or security risk.

320.8.2 Restricted Repositories shall require need-to-know access, stricter logging, periodic access review, limited external collaboration, restricted forking, restricted downloads where feasible, and release gates.

320.9 Controlled Repository.

320.9.1 A Controlled Repository shall be used for materials requiring controlled-room-like restrictions, including no-download access where feasible, special access authorization, heightened monitoring, sealed issue handling, protected knowledge restrictions, public authority restrictions, or export-control restrictions.

320.9.2 Controlled Repositories shall have a recorded charter or equivalent control record identifying permitted users, permitted uses, prohibited uses, AI-use restrictions, export restrictions, publication restrictions, closeout, and correction path.

320.10 Archive Repository.

320.10.1 An Archive Repository shall preserve historical versions, deprecated assets, superseded assets, withdrawn assets, retired assets, old releases, issue records, correction history, vulnerability history, provenance, and technical memory.

320.10.2 Archive Repositories shall be labeled to prevent use of obsolete materials as current authority.

320.10.3 Archive access may be restricted where archived materials contain sensitive information, vulnerabilities, protected knowledge, public authority restricted materials, secrets history, or legal hold records.

320.11 Identity Verification.

320.11.1 Repository access shall be granted only to verified persons, roles, service accounts, bots, applications, or systems according to repository access class and risk.

320.11.2 External collaborators, maintainers, contributors with elevated access, public authority participants, providers, vendors, contractors, fellows, volunteers, and service accounts shall be verified and approved before being granted material repository access.

320.11.3 Shared repository accounts shall be prohibited for material repositories unless an approved service-account exception is recorded with compensating controls.