# III. STANDARDS

Nexus Agile Framework Standards defines the **NAF standards and interoperability discipline**. It explains how Nexus work stays standards-aware across public-good delivery, data, AI, software, cyber, telecom, compute, reporting, and lawful handoff.

This section covers **standards awareness**, **protocol interfaces**, **interoperability**, **conformance questions**, and **testing boundaries**. It shows how Nexus maps to relevant standards and frameworks without claiming standards authority, certification, compliance approval, or deployment authorization.

### What this section covers

* **Standards awareness** - Identifies relevant standards, protocols, frameworks, and interoperability needs.
* **Conformance discipline** - Records standards questions, mappings, and testing without overclaim.
* **Interoperability rules** - Defines how data, software, AI, APIs, workflows, and handoff packages remain portable and legible.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [I. FOUNDATIONS](/organization/operations/frameworks/nexus-agile-framework-naf/i.-foundations.md) for constitutional rules, and [II. SYSTEMS](/organization/operations/frameworks/nexus-agile-framework-naf/ii.-systems.md) for system architecture and role separation.

## 3.1 Standards-Aware Operating Doctrine

### 3.1.1 Standards Awareness as Delivery Discipline.

3.1.1.1 NAF shall be standards-aware as a matter of delivery discipline. Standards awareness means that Nexus work shall be designed, classified, documented, reviewed, released, routed, corrected, and handed off with conscious regard to relevant public-good, technical, data, AI, cyber, privacy, climate, disaster-risk, telecom, compute, digital-public-infrastructure, open-source, innovation-management, accessibility, interoperability, and sectoral standards, protocols, frameworks, taxonomies, guidelines, regulatory interfaces, and institutional practices.

3.1.1.2 Standards awareness under NAF shall not be limited to legal compliance or formal conformance. It shall include the practical operating ability to identify which standards, protocols, data models, APIs, reporting formats, evidence structures, risk taxonomies, security controls, model-governance practices, public-safe communication rules, digital-public-good criteria, and national localization requirements are relevant to a Docket item, output, platform, Studio workflow, Grid input, TRL note, Report, Marketplace listing, Registry record, Nexus Universe output, or lawful handoff package.

3.1.1.3 Standards awareness shall be integrated into the lifecycle of NAF work. At intake, NAF shall identify potentially relevant standards and protocol interfaces. At classification, NAF shall record standards relevance, interoperability dependencies, and sensitivity constraints. At build and review, NAF shall record alignment, divergence, assumptions, limitations, testing profiles, conformance questions, and gaps. At release, NAF shall publish only the standards claims that are supported by record. At handoff, NAF shall transfer standards dependencies and unanswered conformance questions without converting them into certification. At correction, NAF shall repair standards overclaims, outdated mappings, incorrect references, interoperability failures, and downstream misinterpretations.

### 3.1.2 Standards Interface Without Standards Authority.

3.1.2.1 NAF may interface with standards, standards bodies, protocols, specifications, technical committees, regulatory guidance, public authority frameworks, open-source governance practices, digital-public-good criteria, disaster-risk and climate-service frameworks, AI and cyber governance frameworks, telecom and compute protocols, and national or sectoral rules. Such interface shall not make NAF a standards authority by default.

3.1.2.2 NAF shall support standards mapping, standards gap records, conformance-question records, interoperability profiles, testing profile records, protocol objects, schema objects, API contract records, data-exchange records, evidence-exchange records, model and system cards, benchmark records, DRI and Observatory metadata, Registry fields, Marketplace metadata, Studio workflow controls, Grid input structures, TRL evidence notes, and handoff dependency records. These outputs shall assist understanding, design, review, interoperability, and lawful handoff; they shall not constitute formal standards adoption, certification, accreditation, legal compliance determination, regulatory approval, public authority approval, or conformance status unless separately issued by a competent authority.

3.1.2.3 Any NAF statement concerning standards shall identify its status. It may state that a standard is relevant, mapped, referenced, considered, partially aligned, used as design input, used as a testing reference, used as a gap-framing reference, used as a handoff dependency, or subject to a conformance question. It shall not state or imply that NAF has certified, approved, accredited, licensed, validated, or determined conformance unless such status is separately and lawfully recorded.

### 3.1.3 Conformance-Question Records Without Certification.

3.1.3.1 NAF shall use Conformance-Question Records to preserve discipline where a Docket item, output, system, dataset, model, workflow, API, repository, digital public good, Studio demonstration, Grid input, TRL note, Report, Marketplace listing, Registry entry, Nexus Universe output, or handoff package raises a question of alignment with a standard, specification, protocol, regulatory expectation, industry practice, public authority rule, or recognized assurance framework.

3.1.3.2 A Conformance-Question Record shall identify the object, the standard or protocol reference, the scope of the question, the evidence reviewed, the evidence missing, the test or mapping performed if any, the relevant assumptions, limitations, jurisdictional context, responsible reviewer, public-safe status, downstream dependency, and correction pathway. It shall also identify whether the question is informational, design-relevant, release-relevant, handoff-relevant, public authority-relevant, finance-readiness-relevant, insurance-readiness-relevant, procurement-relevant, safety-relevant, privacy-relevant, cyber-relevant, or safeguard-relevant.

3.1.3.3 A Conformance-Question Record shall not itself be a certification, compliance opinion, accreditation, audit conclusion, public authority approval, procurement qualification, financeability determination, insurance approval, safety approval, or deployment authorization. It is a bounded record of a question and the evidence presently available to evaluate that question.

### 3.1.4 Interoperability as Public-Good Capability.

3.1.4.1 NAF shall treat interoperability as a public-good capability. Interoperability enables public-good software, data, methods, models, dashboards, APIs, reports, credentials, proofs, registries, marketplaces, Studio workflows, Grid inputs, TRL notes, DRI indicators, GRIx categories, Observatory signals, National Portfolio objects, Nexus Universe outputs, and lawful handoff packages to be understood, reused, localized, compared, corrected, and transferred without unnecessary lock-in, duplication, semantic drift, or institutional capture.

3.1.4.2 Interoperability under NAF shall include technical interoperability, semantic interoperability, organizational interoperability, legal interoperability, data interoperability, AI workflow interoperability, evidence interoperability, risk taxonomy interoperability, credential interoperability, Registry interoperability, Marketplace interoperability, Studio workflow interoperability, Grid and TRL interoperability, publication interoperability, and handoff interoperability.

3.1.4.3 Interoperability shall be pursued through open interfaces where safe, controlled interfaces where necessary, common metadata, clear schemas, controlled vocabularies, versioned APIs, portable records, public-safe summaries, language localization, accessibility controls, rights and license clarity, secure-room and data-room rules, national data sovereignty controls, and correction pathways. Interoperability shall not require unrestricted openness where data, security, privacy, protected knowledge, public authority sensitivity, community safeguards, Indigenous protocols, cyber safety, geospatial sensitivity, or lawful restrictions require control.

### 3.1.5 Protocol Mapping as Evidence, Not Approval.

3.1.5.1 NAF may use protocol mapping to compare Nexus objects, workflows, datasets, models, APIs, software, Reports, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, National Portfolio objects, and handoff packages against relevant technical protocols, data models, interoperability requirements, reporting formats, terminology systems, cybersecurity baselines, AI governance structures, climate and disaster-risk frameworks, telecom interfaces, compute workflows, or open-source practices.

3.1.5.2 Protocol mapping shall be treated as evidence of relationship, not approval. A protocol map may show similarity, dependency, gap, partial alignment, implementation pathway, translation need, or testing requirement. It shall not state or imply formal conformance, regulatory compliance, certification, public authority approval, procurement eligibility, financeability, insurance approval, provider validation, deployment authorization, or execution readiness unless such effect is separately and lawfully recorded by a competent authority.

3.1.5.3 Protocol mapping records shall include scope, version, mapping method, mapped fields, unmapped fields, assumptions, gaps, reviewer, date, applicable jurisdiction or context, release class, correction pathway, and archive rule. Where protocol mappings are used downstream, the downstream record shall preserve the limitations of the original mapping.

### 3.1.6 Standards Gaps as Docket Items.

3.1.6.1 Standards gaps shall be docketable work. Where NAF identifies missing, outdated, ambiguous, conflicting, inaccessible, non-localized, non-interoperable, unsafe, overly proprietary, under-specified, jurisdictionally uncertain, or operationally impractical standards, protocols, schemas, taxonomies, APIs, metadata fields, evidence templates, cybersecurity controls, AI governance practices, data rules, or reporting formats, such gaps may become Docket items.

3.1.6.2 Standards-gap Docket items may be routed to Nexus Labs for research, Nexus Foundry for protocol object production, DICE for data and commons governance, GRIx for terminology work, DRI for risk-intelligence structuring, Nexus Observatory for signal and metadata requirements, Nexus Studio for workflow testing, Nexus Reports for public-safe publication, Nexus Registry for status records, Nexus Marketplace for discovery, Nexus Grid for readiness inputs, Nexus Academy or Risk Academy for learning, Nexus Universe for convergence, National Nodes for localization, or lawful handoff pathways for competent actor review.

3.1.6.3 A standards-gap Docket item shall not imply that NAF has authority to create, amend, certify, or adopt a formal standard. It shall record a public-good need, evidence gap, interoperability problem, or handoff dependency and may support engagement with competent standards, public authority, industry, academic, or technical bodies.

### 3.1.7 National Localization Without Semantic Drift.

3.1.7.1 NAF shall support national localization without semantic drift. National localization may include translation, legal-context adaptation, public authority terminology, sector terminology, local hazards, data classifications, community safeguards, Indigenous protocols where applicable, infrastructure context, finance-readiness context, insurance-readiness context, procurement terminology, standards references, and public-safe communication formats.

3.1.7.2 Localization shall preserve the meaning, boundary notices, no-conversion rules, role separation, evidence scope, review status, data-use label, AI-use label, public-safe classification, release class, support class, correction pathway, and archive rule of the original object unless a recorded and reviewed localization decision changes the object within a defined scope.

3.1.7.3 NAF shall prevent localization from creating unrecorded approvals or altered claims. Translation shall not constitute substantive approval. Localized terminology shall not create national adoption. National format alignment shall not create public authority approval. Localized standards mapping shall not create formal conformance. Community language adaptation shall not imply community consent. Indigenous-language adaptation shall not imply Indigenous consent or protected knowledge permission.

### 3.1.8 Correction of Standards Overclaim.

3.1.8.1 NAF shall correct standards overclaims. A standards overclaim occurs when any actor represents or implies that a Nexus object, output, record, workflow, dataset, model, software component, report, listing, Registry status, Studio demonstration, Grid input, TRL note, Nexus Universe output, or handoff package has achieved certification, accreditation, legal compliance, standards conformance, public authority approval, procurement readiness, financeability, insurance approval, safety approval, or deployment authorization beyond the recorded scope.

3.1.8.2 Standards overclaims may arise through public language, metadata, Marketplace listings, Registry records, Reports, Campaign materials, sponsor statements, provider statements, public authority learning summaries, finance-readiness rooms, insurance-reader rooms, Studio demonstrations, Nexus Universe presentations, technical documentation, repository README files, API documentation, dashboards, or handoff packages.

3.1.8.3 Correction may include claim revision, public-safe notice, Registry status update, Marketplace delisting or modification, Report erratum, repository correction, Studio workflow restriction, Grid or TRL downgrade, Campaign claims freeze, handoff recall, sponsor or provider notice, public authority clarification, archive action, or reinstatement where appropriate. Correction shall propagate to downstream records that relied on the overclaimed standard, protocol, conformance, or approval status.

## 3.2 Disaster Risk, Climate, Weather, and Resilience Interfaces

### 3.2.1 Disaster-Risk-Reduction Interface Logic.

3.2.1.1 NAF shall maintain disaster-risk-reduction interface logic for work involving hazard exposure, vulnerability, resilience capacity, prevention, mitigation, preparedness, response-learning, recovery-learning, reconstruction-learning, risk governance, critical infrastructure, community resilience, WFEH-B systems, cascading risk, and all-hazards systems transformation.

3.2.1.2 DRR-related NAF work shall be classified according to hazard type, exposure context, vulnerability context, affected systems, geographic sensitivity, community sensitivity, public authority relevance, data sensitivity, public-safe status, evidence level, uncertainty, confidence where applicable, and handoff dependencies. It may be routed to DRI, GRIx, DICE, Nexus Observatory, Nexus Studio, Nexus Reports, Nexus Academy, Risk Academy, Nexus Foundry, Nexus Campaigns, Nexus Grid, Nexus Universe, National Portfolios, or lawful handoff pathways.

3.2.1.3 DRR interface records shall not convert risk-reduction learning into public warning, emergency command, government decision, insurance score, investment signal, procurement decision, certification, community consent, Indigenous consent, or implementation authorization.

### 3.2.2 Weather, Climate, Hydrology, and Early-Warning Interface Logic.

3.2.2.1 NAF shall support weather, climate, hydrology, and early-warning interface logic where Nexus work involves climate services, hydrometeorological data, flood risk, drought risk, heat risk, storm risk, wildfire conditions, coastal hazards, water systems, food systems, energy resilience, health resilience, infrastructure resilience, early-warning dependencies, sensor systems, remote sensing, digital twins, DRI indicators, Observatory signals, or public authority learning.

3.2.2.2 NAF may record data sources, model sources, forecast-source dependencies, observation-source dependencies, sensor dependencies, public authority dependencies, uncertainty, confidence, update cadence, public-safe interpretation limits, sensitive geospatial controls, data rights, and publication restrictions. Where official weather, climate, hydrology, or early-warning authority is relevant, the relevant public authority dependency shall be recorded.

3.2.2.3 NAF shall not become a meteorological, hydrological, climate-service, public warning, emergency alert, evacuation, or operational command authority by implication. NAF may support learning, evidence, public-safe summaries, dashboards, scenarios, and handoff context, but official warnings and operational actions shall remain with competent authorities.

### 3.2.3 Multi-Hazard Early Warning as Public Authority Dependency, Not NAF Warning Authority.

3.2.3.1 NAF may support work relevant to multi-hazard early warning, including risk knowledge, monitoring and observation, communication pathways, preparedness capabilities, community awareness, data interoperability, sensor networks, digital public goods, dashboards, public authority learning rooms, Studio scenarios, DRI indicators, Observatory records, and public-safe education.

3.2.3.2 Where a NAF output concerns early warning, the record shall identify the distinction between public-good learning and official warning authority. The record shall state whether the output is educational, analytical, demonstrative, research-oriented, readiness-oriented, public authority learning-oriented, or handoff-oriented. It shall not be presented as an official warning unless issued by a competent authority under its own legal process.

3.2.3.3 Multi-hazard early-warning interface records shall include public authority dependencies, communication limitations, data limitations, uncertainty, confidence where applicable, update cadence, language limitations, accessibility limitations, community safeguards, sensitive location controls, and correction pathway. Public-safe summaries shall avoid emergency instruction unless expressly authorized by a competent public authority.

### 3.2.4 Climate Adaptation and Resilience Planning Interfaces.

3.2.4.1 NAF shall support climate adaptation and resilience planning interfaces where work involves national adaptation priorities, local resilience planning, infrastructure adaptation, nature-based solutions, WFEH-B resilience, disaster-risk reduction, resilient livelihoods, public health adaptation, climate-finance readiness, insurance-readiness, public authority learning, community safeguards, Indigenous protocols where applicable, and digital public goods for adaptation.

3.2.4.2 Climate adaptation records shall identify climate data sources, scenario assumptions, model limitations, exposure and vulnerability context, resilience-capacity indicators, adaptation options, public authority dependencies, finance-readiness questions, insurance-readiness questions, community participation boundaries, protected knowledge controls, and lawful handoff dependencies.

3.2.4.3 NAF shall not represent climate adaptation interface work as public authority adoption, environmental approval, regulatory compliance, climate-finance approval, insurance approval, procurement readiness, community consent, Indigenous consent, or project authorization unless separately and lawfully recorded.

### 3.2.5 Risk Information, Exposure, Vulnerability, and Resilience-Capacity Records.

3.2.5.1 NAF shall support structured Risk Information, Exposure, Vulnerability, and Resilience-Capacity Records. Such records may include hazard information, exposed assets, exposed populations, infrastructure dependencies, ecosystem dependencies, social vulnerability indicators, institutional capacity indicators, data limitations, uncertainty, confidence where applicable, temporal relevance, geospatial sensitivity, public-safe status, and correction pathway.

3.2.5.2 These records shall support National Portfolios, DRI, GRIx, Nexus Observatory, Nexus Studio, Nexus Reports, Nexus Grid, Nexus Universe, public authority learning, finance-readiness questions, insurance-readiness questions, and lawful handoff context. They shall not be used to rank communities, countries, providers, or projects by default.

3.2.5.3 Risk information records shall not constitute official hazard maps, public warnings, insurance ratings, investment ratings, regulatory determinations, procurement scores, public authority decisions, or implementation instructions unless separately and lawfully issued by a competent actor.

### 3.2.6 Humanitarian and Crisis-Learning Interfaces.

3.2.6.1 NAF shall support humanitarian and crisis-learning interfaces where work involves crisis lessons, after-action reviews, emergency-management learning, humanitarian data, logistics learning, community impacts, displacement, public health emergencies, conflict-sensitive conditions, infrastructure outages, degraded-mode operation, and resilience recovery.

3.2.6.2 Humanitarian and crisis-learning records shall be handled with heightened attention to data protection, dignity, do-no-harm principles, public-safe reporting, sensitive location masking, protected populations, youth safeguards, community safeguards, conflict sensitivity, humanitarian neutrality where relevant, public authority boundaries, and operational-security risks.

3.2.6.3 NAF crisis-learning outputs shall not constitute humanitarian operational command, emergency response order, public warning, official needs assessment, aid allocation decision, public authority decision, procurement decision, or implementation authorization by default.

### 3.2.7 DRR, DRF, and DRI Interoperability Notes.

3.2.7.1 NAF shall maintain DRR, DRF, and DRI Interoperability Notes where disaster-risk reduction, disaster-risk finance, and disaster-risk intelligence work intersect. Such notes shall identify shared terminology, risk-layering questions, protection-gap questions, exposure and vulnerability records, resilience-capacity records, insurance-readiness questions, donor-readiness questions, public finance relevance, DRI indicator structures, and lawful handoff dependencies.

3.2.7.2 DRR, DRF, and DRI Interoperability Notes shall help actors understand relationships among risk reduction, risk financing, risk intelligence, resilience investment, public authority learning, and public-good capability formation. They shall not create insurance approval, finance approval, donor commitment, public finance allocation, investment advice, underwriting, risk rating, procurement status, or public authority decision.

3.2.7.3 Such notes shall be bounded by no-reliance language where capital readers, insurers, donors, or public finance readers may use them for independent learning or diligence framing.

### 3.2.8 Public-Safe Disaster-Risk Communication Controls.

3.2.8.1 NAF shall require public-safe disaster-risk communication controls for all public or semi-public outputs concerning hazards, risk, disasters, climate, vulnerability, exposure, resilience, early warning, crisis learning, or risk intelligence. Public-safe controls shall prevent panic, false certainty, official-warning overclaim, stigmatization, country ranking, community blaming, sensitive location exposure, protected knowledge disclosure, operational-security risk, and misuse by third parties.

3.2.8.2 Disaster-risk communication shall be classified by audience, release class, sensitivity, public authority dependency, language, accessibility, uncertainty, confidence where applicable, and correction pathway. Where information may be misunderstood as warning, official forecast, emergency instruction, or public authority direction, the output shall include clear notices and may require public authority review or restriction.

3.2.8.3 Public-safe disaster-risk communication shall remain evidence-bearing and correctionable. It shall not trade safety for visibility, campaign momentum, sponsor interest, media attention, provider promotion, or finance-readiness presentation.

## 3.3 Digital, Telecom, Compute, and Network Interfaces

### 3.3.1 Digital Infrastructure and Telecom Relevance.

3.3.1.1 NAF shall recognize digital infrastructure and telecom as foundational to public-good systems delivery, disaster resilience, WFEH-B continuity, public authority learning, data commons, AI workflows, observability, Studio environments, Nexus Core Build, National Nodes, Marketplace discovery, Registry access, Reports distribution, Campaign mobilization, Academy learning, and lawful handoff.

3.3.1.2 Digital infrastructure and telecom interface records may include connectivity requirements, network dependency records, edge dependency records, cloud dependency records, compute dependency records, data residency requirements, cyber controls, interoperability profiles, service continuity assumptions, degraded-mode requirements, accessibility requirements, low-bandwidth access, offline access, provider-neutrality notes, public authority dependencies, and handoff conditions.

3.3.1.3 Digital infrastructure relevance shall not imply provider endorsement, telecom regulatory approval, spectrum authorization, service-level warranty, public authority approval, procurement preference, deployment authorization, or operational control.

### 3.3.2 AI-RAN, O-RAN, Private Wireless, Edge, and Future-Network Interoperability.

3.3.2.1 NAF shall support interoperability discipline for AI-RAN, O-RAN, private wireless, edge architectures, sensor networks, mission-critical communications, emergency connectivity, industrial networks, public authority learning networks, and future-network environments relevant to Nexus work.

3.3.2.2 Network interoperability records may include architecture notes, interface references, openness assumptions, vendor-neutrality records, spectrum dependencies, edge compute dependencies, latency needs, resilience needs, cybersecurity controls, AI workflow controls, observability linkages, public authority dependencies, test profiles, Studio demonstration records, Grid inputs, TRL notes, and handoff dependency packages.

3.3.2.3 NAF network records shall not constitute telecom regulatory approval, spectrum permission, network certification, vendor validation, procurement recommendation, service guarantee, public authority decision, deployment authorization, or operational command.

### 3.3.3 Spectrum and Telecom Regulatory Dependency Records.

3.3.3.1 Where NAF work involves spectrum, telecommunications infrastructure, radio access networks, private wireless, satellite communications, emergency communications, edge networks, public safety communications, or regulated connectivity, Spectrum and Telecom Regulatory Dependency Records shall be created where relevant.

3.3.3.2 Such records shall identify the jurisdiction, spectrum dependency, licensing issue, equipment dependency, operator dependency, public authority dependency, standards relevance, testing profile, cyber and resilience considerations, lawful recipient responsibilities, and unresolved regulatory questions.

3.3.3.3 Spectrum and telecom dependency records shall not grant spectrum rights, approve equipment, authorize operation, approve deployment, validate providers, or replace telecom regulators, spectrum authorities, public safety authorities, or competent public authorities.

### 3.3.4 Cloud, HPC, Sovereign Compute, and Secure Enclave Interfaces.

3.3.4.1 NAF shall support cloud, HPC, sovereign compute, and secure enclave interfaces where work requires scalable computation, sensitive data processing, AI evaluation, geospatial analysis, digital twin simulation, risk modelling, DRI analytics, Observatory workflows, Studio workflows, public authority learning, Nexus Core Build, or controlled handoff preparation.

3.3.4.2 Compute interface records shall identify compute environment, workload classification, jurisdictional context, data residency, access controls, security controls, cost and support records, provider-neutrality notes, logging, reproducibility, verifiable execution notes where applicable, teardown rules, archive rules, and handoff dependencies.

3.3.4.3 Compute environment access shall not create data rights, public authority approval, provider validation, service warranty, financeability, procurement readiness, deployment authorization, or execution authority. Sovereign compute relevance shall not itself constitute public authority decision or national endorsement.

### 3.3.5 Compute-to-Data and Restricted-Data Workflow Interfaces.

3.3.5.1 NAF shall support compute-to-data and restricted-data workflow interfaces as preferred patterns for sensitive, sovereign-sensitive, public authority-sensitive, rights-bearing, community-sensitive, Indigenous protocol-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, or protected knowledge data where raw data export would be inappropriate.

3.3.5.2 Compute-to-data records shall identify approved users, approved workloads, approved queries, permitted outputs, output review process, no-download controls, access logs, privacy-preserving analytics, secure enclaves, clean rooms, controlled rooms, confidential computing where applicable, incident response, correction pathway, and archive rule.

3.3.5.3 Compute-to-data access shall not create data ownership, unrestricted data rights, AI training permission, public authority approval, handoff permission, deployment authorization, or execution authority. Outputs shall be reviewed and classified before public release or downstream use.

### 3.3.6 Network Resilience and Degraded-Mode Records.

3.3.6.1 NAF shall support Network Resilience and Degraded-Mode Records for work involving disaster conditions, infrastructure disruption, emergency communications, public authority learning, WFEH-B continuity, field operations, offline access, low-bandwidth access, edge operation, resilient repositories, replicated records, backup and recovery, and continuity of public-good digital infrastructure.

3.3.6.2 Degraded-mode records shall identify critical functions, fallback modes, offline packages, synchronization assumptions, data integrity risks, security risks, user access limits, public-safe communication limits, update cadence, restoration dependencies, and correction rules.

3.3.6.3 Network resilience records shall not create service guarantees, emergency command authority, operational readiness certification, provider validation, public authority approval, procurement status, or deployment authorization.

### 3.3.7 Open API, SDK, Connector, and Adapter Profiles.

3.3.7.1 NAF shall support open API, SDK, connector, and adapter profiles where safe and useful for interoperability among DICE, GRIx, DRI, Nexus Observatory, Nexus Studio, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Grid, Nexus Academy, Nexus Campaigns, Nexus Foundry, Nexus Universe, National Nodes, public-good repositories, and lawful handoff recipients.

3.3.7.2 API and connector profiles shall record purpose, scope, authentication, authorization, rate limits, data minimization, logging, versioning, deprecation, public-safe output filtering, license status, support class, security review, abuse prevention, correction pathway, and archive rule.

3.3.7.3 API availability shall not create data rights, unrestricted access, provider validation, production-readiness certification, service warranty, procurement status, public authority approval, or deployment authorization.

### 3.3.8 Provider-Neutral Infrastructure Records.

3.3.8.1 NAF shall require provider-neutral infrastructure records where infrastructure, cloud, compute, telecom, network, data platform, model platform, cybersecurity tooling, AI tooling, observability tooling, or Studio tooling is used, demonstrated, referenced, listed, or handed off.

3.3.8.2 Provider-neutral infrastructure records shall identify the provider’s role, contribution, support class, conflicts, dependencies, portability assumptions, lock-in risks, alternative pathways where relevant, data residency conditions, security obligations, cost assumptions, support boundaries, and correction pathway.

3.3.8.3 Provider participation or infrastructure contribution shall not create provider validation, preferred supplier status, procurement recommendation, service warranty, public authority approval, financeability, insurance approval, or implementation authorization.

## 3.4 AI, Data, Cyber, and Digital Trust Interfaces

### 3.4.1 AI Risk-Management Interface Records.

3.4.1.1 NAF shall maintain AI Risk-Management Interface Records for work involving AI systems, agentic workflows, model evaluation, AI-assisted analysis, AI-generated outputs, AI-enabled dashboards, AI-supported public authority learning, AI-assisted public-safe reporting, AI-supported DRI, AI-supported Observatory workflows, AI-enabled Studio workflows, AI-assisted coding, AI-assisted research, or AI-supported handoff packages.

3.4.1.2 AI risk-management records shall identify intended use, prohibited use, user class, data basis, model basis, evaluation basis, limitations, risk class, human review, bias and harm review, prompt-injection controls, tool-permission controls, agentic restrictions, output classification, public-safe status, incident response, withdrawal rules, and correction pathway.

3.4.1.3 AI risk-management records shall not certify AI safety, approve deployment, authorize automated decisions, create public authority determinations, validate providers, confirm legal compliance, establish financeability, or confer procurement readiness.

### 3.4.2 AI Management-System Interface Records.

3.4.2.1 NAF shall support AI Management-System Interface Records where AI governance requires structured accountability for policies, roles, risk assessments, data controls, model controls, human oversight, incident response, monitoring, evaluation, documentation, auditability, and continuous improvement.

3.4.2.2 Such records shall help Nexus objects remain interoperable with organizational AI governance systems and lawful recipient processes. They may support handoff context by identifying what an enterprise, public authority, National Consortium Company, Project SPV, provider, operator, or other recipient must assess independently before use.

3.4.2.3 AI management-system interface records shall not create AI management certification, compliance certification, public authority approval, procurement eligibility, insurance approval, financeability, or deployment authorization by default.

### 3.4.3 Model Card, System Card, Benchmark Card, and Agent Workflow Card Alignment.

3.4.3.1 NAF shall require appropriate alignment with structured documentation practices for model cards, system cards, benchmark cards, and agent workflow cards where AI, models, automated workflows, simulations, digital twins, risk models, classification systems, forecasting tools, optimization tools, or agentic systems are involved.

3.4.3.2 These cards shall record object identity, version, purpose, intended use, prohibited use, users, data, evaluation, benchmark scope, assumptions, limitations, performance boundaries, safety controls, human oversight, security controls, public-safe status, incident history, withdrawal rules, and correction pathway.

3.4.3.3 A card shall not be interpreted as validation, safety certification, benchmark superiority, general-purpose approval, public authority approval, procurement readiness, financeability, insurance approval, or deployment authorization. It is a structured record for transparency, review, and correction.

### 3.4.4 Cybersecurity and Zero-Trust Interface Records.

3.4.4.1 NAF shall maintain cybersecurity and zero-trust interface records for software, data, APIs, repositories, Studio workflows, secure rooms, cloud environments, compute environments, networks, edge systems, Observatory nodes, DRI dashboards, Registry platforms, Marketplace platforms, Campaign platforms, Academy platforms, and handoff packages.

3.4.4.2 Cybersecurity records shall include identity and access management, least privilege, authentication, authorization, encryption where appropriate, secrets management, dependency scanning, SBOM records, vulnerability disclosure, threat modelling, logging, monitoring, backup and recovery, incident response, public-safe disclosure controls, and correction pathway.

3.4.4.3 Cybersecurity review shall not constitute security certification, compliance certification, production approval, service guarantee, provider validation, public authority approval, or deployment authorization.

### 3.4.5 Privacy, Data Protection, Data Sovereignty, and Cross-Border Transfer Interface Records.

3.4.5.1 NAF shall require privacy, data protection, data sovereignty, and cross-border transfer interface records where personal data, sensitive data, youth data, health data, public authority data, community-sensitive data, Indigenous protocol-sensitive data, protected knowledge, infrastructure-sensitive data, cyber-sensitive data, geospatial-sensitive data, or restricted data are involved.

3.4.5.2 These records shall identify data controller or steward context where applicable, purpose limitation, data minimization, lawful basis or permission context where applicable, consent and permissions, access controls, retention, deletion, sealing, localization, data residency, transfer restrictions, compute-to-data needs, output review, incident response, and correction pathway.

3.4.5.3 Privacy and data protection interface records shall not constitute legal compliance opinions, public authority approval, unrestricted data rights, AI training permission, handoff permission, or deployment authorization unless separately and lawfully determined by competent actors.

### 3.4.6 SBOM, Dependency, Vulnerability, and Secure Software Interface Records.

3.4.6.1 NAF shall support SBOM, dependency, vulnerability, and secure software interface records for public-good software, repositories, APIs, SDKs, connectors, adapters, dashboards, notebooks, model pipelines, infrastructure-as-code, Studio workflows, Registry systems, Marketplace systems, Campaign systems, Academy systems, and handoff packages.

3.4.6.2 Such records shall identify dependencies, versions, known vulnerabilities, license risks, maintenance status, support class, security review status, vulnerability disclosure channel, patch status, deprecation status, correction pathway, and archive rule.

3.4.6.3 SBOM and vulnerability records shall improve transparency and correctionability without creating warranty, security certification, procurement approval, provider validation, production-readiness certification, or deployment authorization.

### 3.4.7 Digital Identity, Credential, Verification, and Proof-Receipt Interface Records.

3.4.7.1 NAF shall support digital identity, credential, verification, and Proof Receipt interface records for learning records, micro-credentials, contribution records, reviewer records, maintainer records, public authority learning participation, Campaign participation, Registry records, Marketplace profiles, Studio access, secure-room access, handoff receipts, correction records, and archive records.

3.4.7.2 Verification records shall identify issuer, subject, scope, evidence basis, validity period, revocation or withdrawal status, privacy controls, disclosure limits, interoperability profile, correction pathway, and archive rule. Proof Receipts shall record that a bounded action occurred within a defined scope.

3.4.7.3 Digital identity, credential, verification, or Proof Receipt records shall not create professional license, employment status, procurement eligibility, public authority approval, certification, consent, financeability, insurance approval, or execution authority by default.

### 3.4.8 AI-Use, Data-Use, and Public-Safe Output Labels.

3.4.8.1 NAF shall require AI-use, data-use, and public-safe output labels where relevant. These labels shall state whether AI use is prohibited, retrieval-only, summarization with review, classification with review, evaluation-only, fine-tuning permitted, training permitted, agentic use prohibited, secure-room AI only, or public-safe AI output only. Data-use labels shall state whether data is open, public-safe, controlled public, restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, youth-related, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, handoff-recipient-only, or archive-only.

3.4.8.2 Public-safe output labels shall identify whether an output is internal, controlled, public-safe summary, controlled public, open public, data-room-only, secure-room-only, Studio-only, handoff-recipient-only, archived, or non-continuing.

3.4.8.3 Labels shall guide use; they shall not by themselves create legal compliance, data rights, AI permission beyond the record, public authority approval, certification, financeability, procurement status, or deployment authorization.

## 3.5 Innovation, Open Source, and Digital Public Goods Interfaces

### 3.5.1 Innovation-Management Interface Records.

3.5.1.1 NAF shall support innovation-management interface records for work involving ideation, research translation, technology scouting, portfolio formation, challenge briefs, Labs streams, Foundry builds, public-good software, open technical baselines, National Portfolio innovation needs, Campaign activation, Nexus Universe convergence, and lawful handoff preparation.

3.5.1.2 Innovation-management records shall identify purpose, strategic fit, stakeholder need, risk context, evidence basis, experimentation scope, review gates, expected outputs, public-good value, national relevance, safeguard conditions, support class, release class, correction pathway, and handoff dependencies.

3.5.1.3 Innovation-management interface records shall not create certification, investment readiness, procurement status, public authority approval, provider validation, sponsor control, market claim, deployment authorization, or execution.

### 3.5.2 Open-Source Governance Interface Records.

3.5.2.1 NAF shall support open-source governance interface records for public-good code, repositories, libraries, APIs, SDKs, connectors, dashboards, notebooks, data pipelines, infrastructure-as-code, test suites, model evaluation tools, documentation, and reference implementations.

3.5.2.2 Open-source governance records shall identify repository steward, maintainer roles, contributor roles, license, contribution rules, code of conduct, security disclosure channel, dependency review, SBOM status, support class, release class, fork governance, issue process, pull request process, documentation standards, public-safe notices, correction pathway, and archive rule.

3.5.2.3 Open-source governance records shall not create warranty, production approval, deployment authorization, provider validation, procurement preference, employment, agency, certification, or public authority approval.

### 3.5.3 Digital Public-Good Object Governance.

3.5.3.1 NAF shall govern digital public-good objects as lifecycle-bearing public-good assets. Digital public-good objects may include software, data, metadata, models, AI agents, ontologies, schemas, APIs, dashboards, digital twins, simulations, notebooks, reports, learning objects, credentials, Campaign objects, Registry records, Marketplace listings, Studio workflows, Grid and TRL records, Proof Receipts, National Portfolio objects, Nexus Universe outputs, Observatory signals, DRI indicators, GRIx categories, DICE objects, and handoff packages.

3.5.3.2 Each material digital public-good object shall have identity, version, steward, source pathway, jurisdictional context, access class, lifecycle state, metadata, license or rights status, review status, support class, public-safe status, sensitivity class, dependency record, correction pathway, and archive rule.

3.5.3.3 Digital public-good object status shall not create certification, warranty, unrestricted rights, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority.

### 3.5.4 Repository, License, Contributor, Maintainer, and Support Records.

3.5.4.1 NAF shall require repository, license, contributor, maintainer, and support records for public-good digital objects where such records are necessary to preserve reuse, attribution, security, legal clarity, public-good continuity, anti-capture controls, and correctionability.

3.5.4.2 Repository records shall identify location, steward, maintainers, access class, contribution rules, license, security practices, support class, release status, issues, dependencies, known vulnerabilities, documentation, changelog, correction history, and archive status. Contributor and maintainer records shall identify roles, scope, conflicts where applicable, review rights, support responsibilities, renewal, downgrade, removal, and archive.

3.5.4.3 License availability, repository visibility, maintainer status, contributor recognition, or support class shall not create warranty, employment, provider validation, procurement status, certification, public authority approval, financeability, insurance approval, or deployment authorization.

### 3.5.5 Open Technical Baselines and Reference Implementations.

3.5.5.1 NAF shall support open technical baselines and reference implementations where they improve public-good capability, interoperability, reproducibility, learning, public-safe demonstration, National Portfolio formation, Nexus Universe preparation, and lawful handoff context.

3.5.5.2 Open technical baselines and reference implementations shall record scope, intended use, prohibited use, dependencies, assumptions, test status, security status, support class, license, documentation, public-safe status, Registry status, Marketplace status, Grid input where applicable, TRL note where applicable, correction pathway, and archive rule.

3.5.5.3 A reference implementation is not production approval. An open technical baseline is not certification. Public availability is not unrestricted use. Demonstration is not deployment. Reuse remains subject to independent diligence by lawful actors.

### 3.5.6 Community Contribution Without Capture.

3.5.6.1 NAF shall support community contribution without capture. Community contribution may include lived-risk knowledge, local context, translation, accessibility work, data review, safeguard concerns, public-safe reporting input, Campaign participation, Academy participation, Foundry contribution, Studio participation, Reports input, and National Portfolio input.

3.5.6.2 Community contribution shall be non-extractive, recorded, protected, permission-aware, public-safe, and correctionable. Where community knowledge is sensitive, protected, location-specific, culturally significant, Indigenous protocol-sensitive, youth-related, health-related, or safety-relevant, it shall be handled through appropriate controls.

3.5.6.3 Community contribution shall not imply consent, endorsement, data ownership transfer, unrestricted publication permission, implementation approval, employment, procurement support, sponsor support, provider validation, or execution authority.

### 3.5.7 Enterprise-Grade Support Without Warranty Overclaim.

3.5.7.1 NAF may enable enterprise-grade support structures for public-good outputs, including documentation, issue management, release notes, support classes, security notices, maintained releases, help pathways, implementation guidance, training, hosted environments, service status, continuity records, and handoff support. Such support may make NAF outputs more usable by public authorities, enterprises, National Consortium Companies, Project SPVs, providers, operators, funders, insurers, universities, and communities.

3.5.7.2 Enterprise-grade support under NAF shall not create warranty by default. Support class shall state the level of support, limits, responsible steward, time period, known issues, dependencies, escalation pathway, correction route, and end-of-support conditions.

3.5.7.3 Support status shall not create service guarantee, security certification, procurement readiness, provider validation, financeability, insurance approval, public authority approval, deployment authorization, or execution responsibility unless separately and lawfully contracted.

### 3.5.8 Anti-Enclosure and Public-Good Continuity Controls.

3.5.8.1 NAF shall include anti-enclosure and public-good continuity controls to prevent public-good objects, records, software, data, methods, ontologies, Reports, learning objects, Campaign objects, Studio workflows, Registry structures, Marketplace metadata, Grid inputs, TRL notes, and Nexus Universe outputs from being captured, enclosed, privatized, hidden, misrepresented, or redirected for improper exclusive benefit.

3.5.8.2 Anti-enclosure controls may include open licensing where safe, controlled licensing where necessary, attribution records, fork governance, no hidden exclusivity, no pay-to-validate, no pay-to-prioritize, sponsor-boundary records, provider-neutrality records, support ledgers, public-good archive, repository mirroring, national localization, and correction of rights claims.

3.5.8.3 Anti-enclosure controls shall not prevent lawful enterprise handoff. They shall ensure that enterprise use remains compatible with public-good records, rights, attribution, safeguards, dependencies, support status, and correction pathways.

## 3.6 Protocol Object Classes

### 3.6.1 Data-Exchange Protocols.

3.6.1.1 Data-Exchange Protocols shall define how data may be described, transferred, accessed, transformed, restricted, summarized, localized, published, routed, corrected, archived, or handed off within NAF. They shall include metadata requirements, data-use labels, rights information, lineage, quality indicators, access class, sensitivity class, AI-use restrictions, public-safe status, retention, deletion, sealing, cross-border controls, and correction rules.

3.6.1.2 Data-Exchange Protocols shall not create data rights, unrestricted reuse, AI training permission, public authority approval, legal compliance determination, handoff permission, or deployment authorization beyond the recorded scope.

### 3.6.2 Evidence-Exchange Protocols.

3.6.2.1 Evidence-Exchange Protocols shall define how evidence packs, method notes, data records, model records, review notes, public-safe summaries, assumptions, dependencies, limitations, confidence labels, uncertainty labels, and correction records move among Nexus pillars, mechanisms, national layers, regional layers, global layers, and lawful handoff recipients.

3.6.2.2 Evidence exchange shall preserve provenance, scope, review status, release class, public-safe status, limitations, and correction pathways. Evidence exchange shall not convert evidence into approval, certification, financeability, insurability, procurement status, public authority decision, consent, or execution.

### 3.6.3 API Contract Protocols.

3.6.3.1 API Contract Protocols shall define API purpose, endpoints, data fields, authentication, authorization, rate limits, logging, versioning, deprecation, data minimization, public-safe output filtering, error handling, abuse controls, security requirements, support class, and correction rules.

3.6.3.2 API Contract Protocols shall not create data rights, unrestricted access, service warranty, provider validation, production approval, procurement status, public authority approval, or deployment authorization.

### 3.6.4 Registry Protocols.

3.6.4.1 Registry Protocols shall define how objects enter, update, suspend, downgrade, withdraw, recall, supersede, archive, or exit Registry status. They shall include object identity, steward, version, lifecycle state, review status, support class, release class, data-use label, AI-use label, public-safe status, provider contribution, sponsor support, public authority participation, correction history, and archive status.

3.6.4.2 Registry Protocols shall preserve status truth without certification. Registry entry shall not constitute approval, validation, compliance, financeability, insurability, procurement eligibility, deployment authorization, or execution authority.

### 3.6.5 Marketplace Listing Protocols.

3.6.5.1 Marketplace Listing Protocols shall define how objects are described, reviewed, listed, searched, discovered, featured, delisted, corrected, archived, or marked non-continuing. They shall include metadata, license, access class, support class, Registry status, public-safe status, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, and correction pathway.

3.6.5.2 Marketplace listing shall support discovery only. It shall not create endorsement, procurement recommendation, provider validation, warranty, finance signal, insurance signal, public authority approval, consent, deployment authorization, or execution.

### 3.6.6 Studio Workflow Protocols.

3.6.6.1 Studio Workflow Protocols shall define how dashboards, simulations, digital twins, AI workflows, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader workflows, insurance-reader workflows, Nexus Universe workflows, and handoff demonstrations are designed, accessed, logged, reviewed, released, corrected, and archived.

3.6.6.2 Studio Workflow Protocols shall include access control, role-based permissions, no-write-back rules, no-command rules, output review, AI-use restrictions, data export restrictions, public-safe restrictions, shutdown triggers, correction triggers, and archive rules. They shall not create deployment authorization, decision authority, public authority action, finance approval, insurance underwriting, certification, or execution.

### 3.6.7 Grid and TRL Evidence Protocols.

3.6.7.1 Grid and TRL Evidence Protocols shall define how readiness inputs, evidence sufficiency records, method quality records, data status, AI-use status, cyber status, public-safe status, safeguard status, support status, repository status, Marketplace status, Registry status, handoff dependency status, TRL notes, downgrade, suspension, withdrawal, reinstatement, and correction are recorded.

3.6.7.2 Grid and TRL protocols shall support bounded readiness memory without certification. They shall not create procurement readiness, financeability, insurability, public authority approval, deployment authorization, maturity certification, or legal compliance determination.

### 3.6.8 Proof Receipt Protocols.

3.6.8.1 Proof Receipt Protocols shall define how bounded proof records are issued, stored, linked, verified, corrected, revoked where applicable, archived, and displayed. Proof Receipts may relate to participation, contribution, review, release, learning, handoff, correction, archive, or other recorded actions.

3.6.8.2 Proof Receipts shall prove occurrence within scope, not substantive authority beyond scope. They shall not create certification, professional license, employment, procurement status, public authority approval, financeability, insurance approval, consent, deployment authorization, or execution.

### 3.6.9 Credential and Learning-Record Protocols.

3.6.9.1 Credential and Learning-Record Protocols shall define how learning records, Integrated Learning Account entries, micro-credentials, badges, WILP records, contribution records, mentor records, reviewer records, public authority learning participation records, and portfolio records are created, verified, displayed, corrected, withdrawn, archived, and ported.

3.6.9.2 Credential and learning records shall not create professional licenses, employment status, hiring decisions, wage guarantees, immigration status, procurement eligibility, public authority approval, deployment authority, or execution authority by default.

### 3.6.10 Handoff Package Protocols.

3.6.10.1 Handoff Package Protocols shall define how lawful handoff dependency packages are assembled, reviewed, released, transmitted, recalled, corrected, archived, and linked to downstream recipient responsibilities. They shall include evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathway, recall pathway, and archive rule.

3.6.10.2 Handoff Package Protocols shall transfer context and dependencies, not authority. Receipt shall not imply approval, finance, insurance, procurement, certification, consent, deployment, or execution.

### 3.6.11 Correction Protocols.

3.6.11.1 Correction Protocols shall define how errors, overclaims, incidents, outdated records, public-safe issues, data issues, AI issues, cyber issues, privacy issues, protected knowledge issues, standards overclaims, public authority boundary issues, finance boundary issues, procurement boundary issues, provider validation issues, sponsor control issues, consent overclaims, handoff overclaims, and execution overclaims are recorded, contained, corrected, propagated, and archived.

3.6.11.2 Correction Protocols may include claims freeze, data freeze, technical freeze, model freeze, API freeze, Marketplace delisting, Registry status update, Report erratum, Studio restriction, Grid downgrade, TRL note correction, Campaign notice, handoff recall, public-safe notice, public repair, archive, and reinstatement where appropriate.

### 3.6.12 Archive Protocols.

3.6.12.1 Archive Protocols shall define how NAF objects, records, Dockets, Reports, software, data, models, Studio workflows, Registry records, Marketplace listings, Grid inputs, TRL notes, Campaign records, learning records, Nexus Universe outputs, handoff packages, correction records, and non-continuation records are preserved, restricted, sealed, linked, described, and made available for historical use.

3.6.12.2 Archive protocols shall include archive metadata, access class, archive-not-current notice, successor link, correction history, license status, public-safe status, retention rule, deletion or sealing rule where applicable, and permitted use. Archive status shall not create current authority.

## 3.7 Conformance and Testing Boundaries

### 3.7.1 Testing Profile Is Not Certification.

3.7.1.1 A testing profile under NAF is a bounded record of how an object, system, workflow, dataset, model, API, software release, protocol object, Studio demonstration, Grid input, TRL note, or handoff package was tested against defined criteria within a defined scope. It is not certification by default.

3.7.1.2 Testing profiles shall state test scope, test environment, test method, evidence, limitations, reviewer, date, version, assumptions, failures, open issues, public-safe status, and correction pathway. Testing shall not be represented as safety certification, standards certification, compliance approval, procurement readiness, public authority approval, financeability, insurability, deployment authorization, or execution readiness unless separately and lawfully certified by a competent authority.

### 3.7.2 Standards Mapping Is Not Standards Adoption by Default.

3.7.2.1 Standards mapping under NAF shall identify relationships between Nexus objects and external standards, protocols, frameworks, guidelines, taxonomies, schemas, controls, or practices. It shall not constitute adoption of the standard by Nexus, a public authority, a national body, a consortium, a recipient, or a lawful implementation actor by default.

3.7.2.2 Standards mapping may inform Dockets, Reports, Registry fields, Marketplace metadata, Studio workflows, Grid inputs, TRL notes, National Portfolios, Nexus Universe outputs, Academy pathways, Foundry builds, and handoff packages. It shall remain bounded by recorded scope and shall be correctable.

### 3.7.3 Interoperability Test Is Not Public Authority Approval.

3.7.3.1 An interoperability test under NAF may show that two or more objects, systems, datasets, APIs, schemas, workflows, repositories, platforms, or records can exchange information or operate together within a defined test context. It shall not constitute public authority approval.

3.7.3.2 Interoperability testing shall not imply regulatory approval, telecom approval, spectrum permission, cybersecurity certification, data protection compliance, procurement approval, financeability, insurance approval, safety approval, deployment authorization, or operational command. Public authority decisions must be separately and lawfully made by competent public authorities.

### 3.7.4 Protocol Reference Is Not Legal Standard by Default.

3.7.4.1 A protocol reference in a NAF record shall not make the referenced protocol a legal standard by default. NAF may reference protocols to support design, interoperability, evidence exchange, data exchange, API contracts, Registry structures, Marketplace listings, Studio workflows, Grid inputs, TRL notes, proof receipts, credentials, handoff packages, correction, or archive.

3.7.4.2 Legal effect arises only where a competent legal, regulatory, standards, contractual, procurement, public authority, or other lawful process gives the protocol such effect. NAF shall not imply legal standard status merely through citation, mapping, testing, adoption in a technical object, or publication.

### 3.7.5 API Availability Is Not Data Right.

3.7.5.1 API availability under NAF shall not create a data right. An API may be open, controlled, internal, data-room-only, secure-room-only, handoff-recipient-only, or otherwise restricted according to its access class, data-use label, AI-use label, license, rights, sensitivity, authentication, authorization, and public-safe status.

3.7.5.2 Users of NAF APIs shall remain subject to access rules, purpose limitations, data minimization, privacy controls, data sovereignty controls, cross-border restrictions, public-safe output rules, abuse controls, logging, rate limits, and correction. API access shall not imply ownership, unrestricted reuse, AI training permission, public authority approval, handoff permission, or deployment authorization.

### 3.7.6 Connector Availability Is Not Provider Validation.

3.7.6.1 Connector availability under NAF shall not validate a provider, platform, vendor, product, service, or implementation actor. A connector may exist for interoperability, data exchange, workflow support, repository access, API integration, Studio use, Marketplace listing, Registry update, Observatory feed, DRI feed, or handoff context.

3.7.6.2 Connector records shall identify provider role, dependency, version, security status, support status, access class, data-use constraints, AI-use constraints, portability assumptions, lock-in risks, correction pathway, and archive rule. Connector availability shall not create procurement preference, provider approval, service warranty, public authority approval, financeability, insurance approval, certification, or deployment authorization.

### 3.7.7 Benchmark Result Is Not General Validation.

3.7.7.1 A benchmark result under NAF shall be interpreted only within the scope of the benchmark. Benchmark records shall identify task, dataset, model or system version, evaluation method, test environment, assumptions, limitations, known weaknesses, uncertainty, reviewer, date, public-safe status, and correction pathway.

3.7.7.2 Benchmark results shall not create general validation, AI safety approval, model approval, system approval, deployment authorization, public authority approval, financeability, insurability, procurement readiness, provider validation, or superiority claim beyond the recorded scope.

### 3.7.8 Conformance Question Remains Bounded Until Separately Decided by Competent Authority.

3.7.8.1 A conformance question shall remain bounded until separately decided by a competent authority, certifying body, standards body, public authority, qualified auditor, contractual counterparty, procurement body, regulated actor, or other lawful decision-maker with jurisdiction or authority to determine the relevant matter.

3.7.8.2 NAF may frame, record, research, test, map, route, and hand off conformance questions. It shall not decide them by default. Until separately decided, every conformance question shall remain a recorded dependency, assumption, gap, or handoff matter subject to correction.

3.7.8.3 The final standards rule of Part III is that NAF shall be deeply standards-aware, protocol-literate, interoperability-oriented, open where safe, controlled where necessary, and enterprise-legible, while never allowing standards references, mappings, tests, benchmarks, protocols, APIs, connectors, cards, dashboards, Registry records, Marketplace listings, Grid inputs, TRL notes, or handoff packages to become certification, public authority approval, procurement status, financeability, insurability, consent, deployment authorization, or execution by implication.


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/operations/frameworks/nexus-agile-framework-naf/iii.-standards.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.