# 36. Nexus Network ### **36.1 Community and Edge Network Purpose** 36.1.1 The Nexus Network is the community, edge, degraded-mode, and resilience connectivity layer of Planetary Nexus Governance. Its purpose is to ensure that the Rail can continue to receive signals, protect participation, maintain observability, support local coordination, preserve records, and communicate public-safe information even where centralized infrastructure is weak, disrupted, captured, inaccessible, unaffordable, or untrusted. 36.1.2 The Nexus Network exists because governance cannot depend entirely on centralized cloud systems, capital-city institutions, large telecommunications providers, or always-on digital infrastructure. Compound risk often appears first at the edge: during floods, fires, storms, heat events, industrial incidents, public-health anomalies, cyber outages, power failures, conflict, displacement, infrastructure breakdown, or public trust collapse. If the Rail cannot operate at the edge, it cannot govern the realities it claims to see. 36.1.3 The Network is not merely communications infrastructure. It is public-good resilience infrastructure. It connects community observatories, local labs, Competence Cells, field nodes, municipal surfaces, public authority interfaces, observatory nodes, sensor systems, emergency communication pathways, controlled data pathways, local evidence routes, and platform synchronization mechanisms. It allows local truth to enter the Rail even when ordinary institutional channels fail. 36.1.4 The Nexus Network may include community mesh networks, peer-to-peer systems, private wireless networks, local radio systems, satellite connectivity, edge servers, local data stores, resilient sensors, offline-first applications, mobile reporting tools, emergency communications kits, community-run networks, local observatory devices, and synchronization pathways into national sovereign cores and Nexus Platforms. The Network should be technologically plural and context-responsive. 36.1.5 The Network must remain public-good, not proprietary enclosure. Connectivity providers, equipment vendors, cloud actors, satellite providers, telecom operators, hosts, sponsors, and technical contributors may support the Network, but no actor should own the public-good rail by controlling the pipes through which local evidence and participation travel. Connectivity is support, not governance authority. 36.1.6 The Network must be designed for people closest to risk. It should support communities, Indigenous and local knowledge holders, public authorities, local responders, local institutions, utilities, observatories, field teams, and Competence Cells with secure and accessible communication. It should not require advanced technical literacy or expensive infrastructure as a condition of participation. 36.1.7 The Network must preserve role separation. A network node may transmit evidence, but it does not validate the evidence. A community router may support observability, but it does not create consent. A local connectivity host may support public-safe communication, but it does not become public authority. A technical operator may maintain systems, but it does not own governance records. 36.1.8 The doctrine is direct: **The Nexus Network gives the Rail resilient community and edge connectivity, ensuring that local evidence, protected participation, observability, and public-safe communication can continue when centralized systems are absent, fragile, disrupted, or untrusted.** *** ### **36.2 Mesh, P2P, Private Wireless, Satellite, and Degraded-Mode Connectivity** 36.2.1 The Nexus Network uses a plural connectivity architecture that may include mesh networks, peer-to-peer systems, private wireless, satellite links, local radio, edge servers, offline-first tools, delay-tolerant synchronization, and degraded-mode communication protocols. Its design assumption is that normal connectivity will fail, be unequal, or be unsafe in the very moments when governance most needs signal. 36.2.2 Mesh networks allow local devices, routers, sensors, community hubs, field nodes, and observatory stations to communicate with one another without relying entirely on centralized infrastructure. They can support neighbourhood-level resilience, local reporting, emergency coordination, community observatories, and degraded-mode public-safe messages. 36.2.3 Peer-to-peer systems may allow trusted nodes to exchange records, receipts, attestations, observations, public-safe notices, and local evidence where centralized servers are unavailable or undesirable. Peer-to-peer design must include identity, encryption, access control, publication classification, data minimization, and revocation. Decentralization is not automatically trust. 36.2.4 Private wireless networks, including local cellular, private 5G, private LTE, Wi-Fi, O-RAN-aligned architectures, and other lawful spectrum-based systems, may support observatories, campuses, industrial sites, utilities, rural regions, emergency zones, ports, remote communities, or national sovereign infrastructure. They must be operated under applicable law and public authority requirements. 36.2.5 Satellite connectivity may support remote, rural, island, disaster-affected, conflict-sensitive, maritime, mountain, forest, polar, or low-infrastructure environments. Satellite links can preserve connectivity where terrestrial systems fail. They must be governed for data sovereignty, cost, dependency, latency, interception risk, vendor dependency, and public authority constraints. 36.2.6 Degraded-mode connectivity is a core design principle. The Network should support operation when bandwidth is low, power is limited, devices are offline, platforms cannot be reached, identity services are degraded, or field teams must operate under emergency conditions. Degraded-mode design may include local caching, offline forms, paper-to-digital intake, SMS or radio gateways, portable power, local synchronization queues, and delayed receipt generation. 36.2.7 Connectivity choices must be context-specific. A rural watershed may need low-power sensors and offline sync. A city heat-response network may need mobile reporting and municipal integration. A disaster zone may need satellite and radio fallback. A data-centre corridor may need private wireless and secure telemetry. A community observatory may need low-cost mesh. The Network must fit place. 36.2.8 Connectivity must never override governance. A technically available link does not create permission to transmit sensitive records. A mesh route does not make data public. A satellite uplink does not authorize cross-border transfer. A private wireless deployment does not create public authority. Every transmission must remain classified, purpose-bound, and correctable. 36.2.9 The doctrine is direct: **The Nexus Network uses mesh, peer-to-peer, private wireless, satellite, and degraded-mode systems so the Rail can communicate under real-world disruption, but every connection remains governed by law, role, classification, safeguards, and correction.** *** ### **36.3 Node Identity** 36.3.1 Node identity is the governance and technical discipline by which each network node is identified, classified, authorized, credentialed, monitored, and corrected within the Nexus Network. A node may be a community hub, sensor, edge server, field device, observatory station, Competence Cell system, municipal gateway, public authority interface, utility telemetry point, satellite terminal, private wireless access point, or platform synchronization endpoint. 36.3.2 Node identity is necessary because a resilience network without identity becomes vulnerable to fraud, spoofing, misinformation, unauthorized access, data poisoning, surveillance, and capture. The Rail must know which node produced, transmitted, stored, transformed, or relayed a record, and under what authority or competence. 36.3.3 Node identity should include node type, host, operator, location or protected location class, lawful basis, technical capability, public authority relationship, community relationship, data classes handled, publication classes permitted, AI-processing permissions, sensor types, security posture, network dependencies, attestation status, competence status, and correction contact. 36.3.4 Node identity must distinguish between host, operator, owner, steward, maintainer, data controller or steward, community authority, public authority, and technical administrator. These roles may be held by different actors. A device maintainer does not necessarily own the data. A host does not necessarily approve outputs. A public authority-connected node does not necessarily create public authority approval. 36.3.5 Node identity must be role-keyed. A node may be authorized to transmit public-safe messages but not restricted evidence. Another may collect environmental telemetry but not personal data. Another may synchronize controlled-room receipts but not export raw data. Another may operate only during incident mode. Node permissions should be specific. 36.3.6 Node identity should be revocable and renewable. Nodes may be suspended if compromised, misconfigured, captured, unsafe, obsolete, conflicted, or inactive. Credentials may expire. Host context may change. Competence may need renewal. Node identity is a living record, not a one-time registration. 36.3.7 Node identity must support privacy and protected location handling. Some nodes, especially community or protected knowledge nodes, may require public anonymity or location masking. The system may need to know identity internally while public outputs show only protected classes. Identity governance must balance auditability and safety. 36.3.8 The doctrine is direct: **Node identity ensures that every participating device, hub, gateway, observatory, and edge system is known within the Rail by role, authority, competence, permission, limitation, and correction path.** *** ### **36.4 Attestation** 36.4.1 Attestation is the process by which a node, actor, device, record, observation, credential, configuration, release, receipt, or network event proves that it meets defined conditions at a defined time for a defined purpose. In the Nexus Network, attestation is the trust-minimizing method through which distributed systems become reliable without relying on reputation alone. 36.4.2 Attestation is necessary because community and edge networks operate in environments where infrastructure may be degraded, participants may be distributed, devices may be unattended, and records may travel through multiple pathways. The Rail must know whether a node is who it claims to be, whether a device is running approved configuration, whether a sensor is calibrated, whether a record was signed by an authorized actor, whether a proof was generated under the right conditions, and whether a receipt remains valid. 36.4.3 Attestation may include device attestation, node attestation, operator attestation, host attestation, sensor attestation, software release attestation, data provenance attestation, evidence receipt attestation, model-use attestation, controlled-room access attestation, network-health attestation, and correction attestation. Each type must state what is being attested and what is not. 36.4.4 Attestation must be scoped. A node attested as technically active is not attested as socially legitimate. A sensor attested as calibrated is not attested as producing public-safe evidence. A person attested as trained is not attested as authorized to decide. A record attested as received is not attested as true. Attestation proves only the condition it states. 36.4.5 Attestation may use cryptographic signatures, secure hardware, trusted execution environments, verifiable credentials, signed receipts, timestamping, hash records, audit logs, peer validation, local witness statements, host verification, TMD review, or other appropriate mechanisms. The method should match consequence and context. Not every setting requires the same technical intensity. 36.4.6 Attestation must remain inclusive. Highly sophisticated technical attestation should not exclude low-resource communities from participation. Where advanced cryptographic infrastructure is unavailable, the Rail may use layered attestation: local witness records, host records, paper-to-digital signatures, community validation, device metadata, and later synchronization. The standard is trustworthy enough for purpose, not maximum complexity everywhere. 36.4.7 Attestation must be correctionable. If a key is compromised, a sensor was miscalibrated, a node was spoofed, a receipt was issued incorrectly, or a configuration was invalid, the attestation must be revoked, corrected, superseded, and propagated to dependent records. 36.4.8 The doctrine is direct: **Attestation allows the Nexus Network to create trust through recorded proof rather than assumed status, while preserving scope, proportionality, inclusiveness, and correction.** *** ### **36.5 Proof-of-Competence, Proof-of-Impact, and Zero-Knowledge Proof** 36.5.1 Proof-of-Competence, Proof-of-Impact, and zero-knowledge proof mechanisms are optional technical and governance instruments through which the Nexus Network may establish competence, demonstrate public-value effects, and verify sensitive conditions without unnecessary disclosure. They support trust-minimized governance where direct exposure of data, identity, or records would be unsafe or excessive. 36.5.2 Proof-of-Competence is the recorded demonstration that an actor, node, Competence Cell, observer, maintainer, field team, community network, or technical function has satisfied defined training, capability, practice, equipment, review, or performance conditions for a specific role. It may support role-key assignment, node activation, evidence-handling authority, sensor operation, public-safe communication, or technical assistance eligibility. 36.5.3 Proof-of-Competence must be role-specific. A person trained in local evidence intake is not automatically competent in cyber incident response. A Cell competent in community observability is not automatically competent in data-centre verification. A node operator competent in mesh maintenance is not automatically competent in protected knowledge handling. Competence proofs must state scope, date, issuer, criteria, and renewal. 36.5.4 Proof-of-Impact is the recorded demonstration that a pathway, intervention, program, observatory, training effort, community network, resilience action, public-safe communication, or infrastructure support produced a defined public-value effect or measurable outcome. It may include evidence of improved resilience, reduced risk, better response time, stronger observability, corrected public claims, increased participation, improved service continuity, or protected community benefit. 36.5.5 Proof-of-Impact must avoid vanity metrics. Counting meetings, downloads, dashboards, nodes, or participants is not enough. Impact should be tied to public value, safeguards, equity, resilience, correction, public authority learning, ecological improvement, service reliability, or reduced harm. Impact claims must be evidence-bearing and correctionable. 36.5.6 Zero-knowledge proof or similar privacy-preserving verification methods may allow the Rail to verify that a condition is satisfied without exposing the underlying sensitive data. For example, a node may prove it holds a valid credential without revealing personal details; a dataset may prove it meets a condition without exporting raw data; a controlled-room process may prove that a check occurred without exposing protected knowledge; a capital-reader process may verify eligibility without accessing restricted records. 36.5.7 Zero-knowledge and privacy-preserving proofs must be used carefully. A cryptographic proof can verify a narrow statement, but it does not prove broader truth, legitimacy, consent, public authority approval, or public value. The proof statement must be precise, understandable, and tied to governance meaning. 36.5.8 Proof systems must not create exclusion, gamification, or tokenized legitimacy. Proof-of-Competence should not become credential elitism. Proof-of-Impact should not become impact theatre. Zero-knowledge proof should not become a black box that hides accountability. All proof mechanisms must remain public-good, scoped, auditable where appropriate, and correctionable. 36.5.9 The doctrine is direct: **Proof-of-Competence, Proof-of-Impact, and zero-knowledge proof strengthen the Nexus Network when they verify specific conditions without unnecessary disclosure, but they must never convert narrow proof into broad authority, legitimacy, consent, or financial claim.** *** ### **36.6 Proof-of-Observability and Sensing Quality** 36.6.1 Proof-of-Observability is the recorded demonstration that a node, sensor network, community observatory, field process, telemetry pathway, dashboard, or observability system is capable of producing observations that meet defined requirements for source, method, coverage, quality, continuity, classification, provenance, and correction. It establishes whether a system can see what it claims to see. 36.6.2 Proof-of-Observability is necessary because false observability is dangerous. A dashboard may display data gaps as truth. A sensor may be uncalibrated. A community report may be stripped of context. A satellite layer may be outdated. A telemetry stream may be spoofed. A model may infer conditions beyond evidence. Without proof of observability, the Rail may mistake visibility for knowledge. 36.6.3 Proof-of-Observability should identify observation purpose, system boundary, node identities, sensors or sources, calibration status, spatial and temporal coverage, data gaps, maintenance records, data-quality rating, provenance, cybersecurity posture, public-safe classification, protected knowledge controls, AI-use status, validation method, limitations, and correction pathway. 36.6.4 Sensing quality includes technical quality and social quality. Technical quality includes accuracy, precision, calibration, uptime, data integrity, timestamp reliability, spatial resolution, cyber security, and maintenance. Social quality includes community trust, source context, participant safety, protected knowledge handling, grievance routes, and local interpretation. A technically accurate sensor system can still be governance-poor if it is socially unsafe. 36.6.5 Proof-of-Observability should distinguish adequate-for-purpose from universally valid. A low-cost community sensor may be adequate for early warning but not regulatory measurement. A satellite layer may be adequate for regional trend analysis but not site-level proof. A digital twin may support scenario exploration but not final prediction. Observability proof must state permitted uses. 36.6.6 TMDs may define or review sensing quality for high-consequence domains. Cyber telemetry, nuclear-adjacent monitoring, industrial-site sensing, public-health surveillance, water quality, biodiversity, energy-grid monitoring, and data-centre telemetry may require specialized technical review. Competence Cells may support local operation, but formal technical claims must remain scoped. 36.6.7 Proof-of-Observability must support correction. If a sensor fails, coverage changes, a node becomes compromised, community trust changes, or validation reveals error, dependent dashboards, evidence packs, maturity states, routeability records, and public-safe outputs must be reviewed. 36.6.8 The doctrine is direct: **Proof-of-Observability ensures that the Rail’s sensing systems are not merely connected, but fit for their stated purpose, technically qualified, socially safe, provenance-aware, and correctionable.** *** ### **36.7 Community Data Pathways** 36.7.1 Community Data Pathways are the governed routes through which community-held, community-generated, locally observed, Indigenous or protected where applicable, household-level, neighbourhood-level, worker-generated, civil society, or local institutional data may enter, remain within, or interact with the Nexus Rail. They ensure that community data supports public-good governance without becoming extraction. 36.7.2 Community Data Pathways are necessary because local evidence can be powerful and sensitive. A community may document water contamination, heat stress, service failure, displacement pressure, biodiversity change, industrial impacts, health concerns, network outages, public authority failures, or public trust conditions. Such evidence may improve governance, but it may also expose people, land, knowledge, livelihoods, or vulnerabilities if mishandled. 36.7.3 A Community Data Pathway should identify who holds or stewards the data, how the data was generated, what permissions apply, what restrictions exist, what publication class applies, what AI processing is prohibited or permitted, what public-safe summary may be produced, what access rights exist, what correction rights apply, and what benefits or feedback return to the community. 36.7.4 Community data must not be treated as free raw material. Public-good purpose does not eliminate rights, dignity, context, consent, data sovereignty, cultural protocols, privacy, or safety. Data should be minimized, classified, and purpose-bound. 36.7.5 Community Data Pathways should support multiple levels of sharing: no sharing; local-only; community-controlled; controlled-room review; public-safe summary; metadata-only; anonymized or aggregated; compute-to-data; TMD review under restriction; national evidence-pack use; regional comparison use; or public release. The community and lawful context should help define the pathway. 36.7.6 Community Data Pathways must include grievance and correction. If community data is misinterpreted, overexposed, used beyond purpose, processed by AI without permission, cited as consent, or used to support downstream finance or execution beyond scope, affected actors must be able to challenge, restrict, correct, or withdraw use where applicable. 36.7.7 Community Data Pathways must also protect against local elite capture. Community data governance should not assume that one local actor represents all affected people. Representation, authority, dissent, vulnerable groups, and intra-community differences must be handled carefully. 36.7.8 The doctrine is direct: **Community Data Pathways allow local truth to strengthen the Rail while preserving community control, protected knowledge, privacy, purpose limitation, public-safe use, feedback, and correction.** *** ### **36.8 Local Resilience Communications** 36.8.1 Local resilience communications are the communication capabilities, protocols, channels, devices, messages, and governance practices through which communities, local institutions, public authorities, observatories, Competence Cells, and field nodes exchange public-safe information before, during, and after disruption. They are the human-facing communication function of the Nexus Network. 36.8.2 Local resilience communications are necessary because crises create both information scarcity and misinformation. During disasters, cyber outages, infrastructure failures, industrial incidents, public-health events, or public authority confusion, people need clear, safe, trusted, and locally understandable information. Central channels may fail or lose trust. Local channels can maintain continuity. 36.8.3 Communication channels may include mesh messages, SMS, radio, satellite messaging, community bulletin points, local dashboards, public-safe alerts, trusted intermediaries, municipal channels, local language summaries, offline forms, public meetings where safe, and accessible formats. The channel should match local capacity and risk. 36.8.4 Local resilience communications must distinguish public-safe governance information from official emergency orders. The Nexus Network may support public-safe communication, situational awareness, correction, and community coordination, but it must not impersonate emergency public authorities unless lawfully authorized. Public authority capacity must be clear. 36.8.5 Messages must be claims-disciplined. They should state what is known, what is uncertain, what authority is speaking, what action is recommended or required by whom, what should not be inferred, and how updates or corrections will occur. False certainty can be as dangerous as silence. 36.8.6 Communications must be accessible. Local messages should account for language, disability, literacy, device access, connectivity limits, cultural context, and trust networks. Resilience communication that reaches only digitally connected elites is inadequate. 36.8.7 Communications must include correction. If a public-safe message is wrong, outdated, mistranslated, overbroad, or misattributed, correction must be issued through the same or stronger channels where possible. Correction should be clear, visible, and timely. 36.8.8 The doctrine is direct: **Local resilience communications keep communities informed and connected under stress, while preserving public authority boundaries, public-safe discipline, accessibility, trust, and correction.** *** ### **36.9 Anti-Fraud and Privacy Controls** 36.9.1 Anti-fraud and privacy controls are the Network’s safeguards against false nodes, false credentials, spoofed data, fabricated impact, identity misuse, unauthorized access, data theft, surveillance, impersonation, financial exploitation, public authority misrepresentation, proof manipulation, and misuse of community or sensitive records. They are essential because a distributed network increases both resilience and attack surface. 36.9.2 Fraud risks may include fake observatory nodes, forged receipts, manipulated sensor data, false proof-of-impact claims, fake public authority references, false community consent claims, credential misuse, provider self-verification, fabricated training records, altered dashboards, spoofed emergency messages, duplicate identities, and misuse of Nexus names or marks. 36.9.3 Privacy risks may include overcollection, reidentification, unauthorized AI processing, location exposure, protected knowledge leakage, health data exposure, worker retaliation, community profiling, cross-border data transfer without authority, platform log misuse, and secondary use for finance, policing, marketing, or political targeting. 36.9.4 Anti-fraud controls may include node identity, attestation, signed receipts, role-keyed access, credential verification, anomaly detection, audit logs, TMD review, peer validation, conflict disclosure, proof revocation, public claims review, mark-use controls, and incident escalation. The control set should match risk and capacity. 36.9.5 Privacy controls may include data minimization, purpose limitation, consent or lawful basis, publication classification, anonymization where appropriate, aggregation, location masking, protected knowledge restrictions, AI-use prohibitions, access logging, retention limits, encryption, sovereign data-zone rules, and grievance routes. 36.9.6 Anti-fraud controls must not become exclusion. Communities in low-resource settings may lack formal documents, advanced devices, or stable connectivity. The Network should support layered trust: local validation, host records, community witnesses, assisted credentialing, delayed attestation, and proportional verification. Anti-fraud must protect the Rail without excluding the people it is built to serve. 36.9.7 Privacy controls must not become secrecy for powerful actors. Operators, providers, sponsors, or public authorities should not misuse privacy language to hide risks, suppress public-safe reporting, avoid correction, or prevent communities from seeing relevant public-good information. Privacy protects people and legitimate sensitive interests, not institutional embarrassment. 36.9.8 The doctrine is direct: **Anti-fraud and privacy controls make the Nexus Network trustworthy by preventing false proof, false identity, data misuse, surveillance, and overclaim while preserving inclusion, public-safe transparency, and correction.** *** ### **36.10 Network Records** 36.10.1 Network Records are the official records through which the Nexus Network proves its identity, connectivity, node status, attestations, competence proofs, observability proofs, data pathways, communications events, incidents, access, corrections, and maturity. Without Network Records, a distributed resilience network becomes technically active but governance-invisible. 36.10.2 Network Records may include node identity records, host records, operator records, device records, connectivity records, mesh topology records where safe, private wireless records, satellite terminal records, edge server records, sensor records, attestation records, proof-of-competence records, proof-of-impact records, proof-of-observability records, zero-knowledge proof statements, community data pathway records, local communication records, incident logs, audit logs, privacy records, fraud reports, correction records, and supersession records. 36.10.3 Network Records must be publication-classified. Some records may be public-safe, such as general network coverage or community resilience capacity. Others must be restricted, including node locations, cyber configurations, protected community pathways, emergency channels, infrastructure dependencies, credentials, telemetry, or sensitive local data. Network transparency must not expose the network to harm. 36.10.4 Network Records must preserve source and authority. A message from a community node, public authority node, Competence Cell node, utility node, TMD node, platform node, or field node has different meaning. Records must show source capacity and reliance limits. 36.10.5 Network Records must include logs sufficient for audit and correction. Where a public-safe message was transmitted, a node attestation changed, a sensor stream failed, a proof was revoked, a data pathway was restricted, or a fraud incident occurred, the record must show what happened, who acted, what authority applied, what correction followed, and what dependent outputs were affected. 36.10.6 Network Records must be interoperable with Observatory Records, Platform Records, National Governance Records, TMD Records, and Correction Trails. A network event may affect evidence packs, dashboards, public-safe communication, routeability records, and incident-mode reviews. Records must connect. 36.10.7 Network Records must support maturity states. A community network, node cluster, private wireless deployment, degraded-mode pathway, or satellite fallback may be forming, pilot, operating, monitored, mature, conditional, suspended, compromised, corrected, superseded, or retired. Stage truth must be visible. 36.10.8 The doctrine is direct: **Network Records make distributed resilience accountable by showing which nodes, links, proofs, data pathways, messages, incidents, and corrections operated within the Nexus Network and under what limits.** *** ### **36.11 Community Networks as Public-Good Resilience Infrastructure** 36.11.1 Community Networks are public-good resilience infrastructure when they are locally grounded, protected, interoperable, non-extractive, privacy-preserving, anti-fraud, correctionable, and connected to the Nexus Rail through governed interfaces. They are not merely technical networks. They are institutional and social capacity for communities to observe, communicate, coordinate, and correct under ordinary and extraordinary conditions. 36.11.2 Community Networks matter because resilience is not only the ability of centralized systems to recover. It is the ability of communities to remain connected, informed, protected, and capable when those centralized systems fail or do not reach them. Community networks can support early warning, mutual aid, local observability, public-safe communication, local evidence, degraded-mode governance, and trust repair. 36.11.3 Community Networks should be designed as public-good commons, not extraction channels. They should strengthen local capacity, return feedback, protect data, support local control, and prevent knowledge enclosure. They should not become devices through which external actors harvest community data, sell services, influence consent, shape land-use decisions, or produce finance-readable narratives without community benefit and safeguards. 36.11.4 Community Networks should be technically plural and locally appropriate. Some communities may use mesh. Others may use radio. Others may use satellite fallback, private wireless, local servers, paper-to-digital intake, or trusted institutional gateways. The correct design is the one that is lawful, usable, maintainable, safe, and trusted in context. 36.11.5 Community Networks must be connected to governance, not isolated as technology pilots. They should have node identity, host truth, data pathways, safeguards, grievance routes, public-safe communication protocols, escalation to national and regional layers, correction trails, training, maintenance, and sustainability plans. A network without governance can become abandoned infrastructure or local surveillance. 36.11.6 Community Networks should support local ownership and capability. External technical actors may assist, but local participants should understand the system, control appropriate records, maintain core functions where feasible, and participate in decisions about data, publication, and use. Resilience requires local agency. 36.11.7 Community Networks must remain non-substitutive of public authority. They may help communities communicate and provide evidence. They may support public-safe messages. They may inform public authorities. They may assist during disruption. They do not become emergency authority, regulator, public health authority, utility authority, or public decision-maker unless lawfully authorized. 36.11.8 Community Networks must be correctionable. If a message is wrong, a node is compromised, data is misused, consent is overstated, a proof is fabricated, or a community is misrepresented, the network must support correction, notification, restriction, and learning. 36.11.9 The final doctrine of this chapter is direct: **The Nexus Network makes community and edge connectivity part of the public-good governance rail. It turns mesh, peer-to-peer, private wireless, satellite, edge nodes, proofs, and local communications into resilience infrastructure, while ensuring that connectivity serves communities, protects data, resists fraud, preserves public authority boundaries, and remains correctionable.** --- # 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/organization/governance/doctrine/vi.-infra/36.-nexus-network.md?ask= ``` 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.