# 77. Community Networks ## Chapter 77. Community Legitimacy and Community-Run Networks ### Planetary Nexus Governance: Foundational Thesis ### **77.1 Community Legitimacy** 77.1.1 Community Legitimacy is the doctrine that Planetary Nexus Governance cannot be legitimate merely because it is technically correct, publicly funded, institutionally endorsed, legally structured, finance-readable, platform-enabled, or expert-reviewed. A pathway that affects people, place, land, water, culture, livelihood, health, safety, identity, local knowledge, community trust, or protected participation must be legible, challengeable, and correctable by the communities it touches. 77.1.2 Community Legitimacy does not mean that every community process substitutes for lawful public authority, or that every community actor may veto every public decision. It means that community truth, community risk, community knowledge, community objection, community dignity, and community correction must have a protected place in the Rail before records, dashboards, proof packs, routeability, public-safe summaries, technical assistance, or implementation handoffs may claim legitimacy. 77.1.3 Community Legitimacy is distinct from consultation. A consultation event may be performative, extractive, inaccessible, mistranslated, unsafe, rushed, or non-consequential. Community Legitimacy requires more: protected participation, clear language, local record access, dissent capture, non-retaliation, grievance routes, correction rights, benefit return, public-safe communication, and evidence that community input can change the pathway. 77.1.4 Community Legitimacy is distinct from community consent. Participation, attendance, training, local data contribution, community sensing, community node involvement, or community representative presence must not be treated as whole-community consent unless the relevant lawful, cultural, institutional, or rights-based standard for consent has been met and recorded. Where Indigenous rights, protected knowledge, land rights, or local governance protocols apply, those standards must be independently respected. 77.1.5 Community Legitimacy requires attention to internal difference. A community is not a single voice. Elders, youth, women, persons with disabilities, workers, tenants, informal residents, migrants, local businesses, farmers, fishers, Indigenous or local knowledge holders, faith groups, public service users, and vulnerable participants may experience risk differently. The Rail must avoid treating the most visible, powerful, connected, or technically literate community actors as the whole community. 77.1.6 Community Legitimacy must be protected from capture. Local elites, political actors, employers, landowners, sponsors, vendors, public authorities, funders, media actors, or external organizations may claim to speak for communities. Community legitimacy requires capacity records, conflict records, representation limits, protected dissent, and routes for excluded or vulnerable participants to raise concerns safely. 77.1.7 Community Legitimacy must affect maturity, routeability, safeguards, dashboards, proof packs, and handoffs. A pathway with weak community legitimacy may need to remain supported-only, paused, narrowed, controlled, locally revalidated, or excluded from finance-readiness until community risks, knowledge, non-consent, accessibility, and correction are resolved. 77.1.8 The doctrine is direct: **Community Legitimacy means that governance touching people and place must be answerable to the people and places it describes. No Nexus pathway is legitimate if community truth cannot safely enter, challenge, restrict, and correct the record.** *** ### **77.2 Community Evidence** 77.2.1 Community Evidence is the local, lived, practical, observational, historical, cultural, ecological, infrastructural, health, livelihood, safety, hazard, and service-use knowledge contributed by communities, workers, local institutions, community nodes, Indigenous and local knowledge holders where applicable, civil society, local media, and place-based actors to the Nexus Rail. 77.2.2 Community Evidence may include flood routes, heat exposure, wildfire behaviour, water access, food insecurity, clinic barriers, disability access barriers, unsafe roads, utility failures, informal infrastructure, worker exposure, public trust conditions, local warning signs, ecological shifts, biodiversity observations, service gaps, public authority responsiveness, cultural heritage risks, protected knowledge restrictions, and lived consequences of technical or financial decisions. 77.2.3 Community Evidence must not be treated as inferior because it is oral, qualitative, informal, local-language, non-digital, experiential, or not produced by credentialed experts. Nor may it be treated as automatically complete, uncontested, or representative. It must be recorded with source capacity, context, sensitivity, uncertainty, validation status, dissent, attribution preference, and correction route. 77.2.4 Community Evidence must be admissible into baselines, dashboards, observatory records, proof packs, public-safe summaries, safeguards reviews, priority registers, technical assistance scopes, routeability gap lists, and maturity reviews. A model, satellite layer, sensor reading, expert report, or finance-readable record that cannot be corrected by community evidence is not governance-grade. 77.2.5 Community Evidence must be protected from extraction. A community report submitted to improve safety must not be repurposed as donor storytelling, AI training data, market intelligence, insurance pricing, procurement justification, capital-reader evidence, media narrative, or public dashboard material without recorded permission, publication-class review, safeguards, and public-safe transformation. 77.2.6 Community Evidence must include negative evidence. Silence, refusal, non-participation, distrust, fear, disagreement, uncertainty, inaccessible process, mistranslation, and absence of safe reporting may themselves be evidence. A lack of recorded objection must never be treated as support where participation was unsafe, unclear, inaccessible, or coercive. 77.2.7 Community Evidence must be returned. Communities contributing evidence should receive usable summaries, corrections, public-safe outputs, local records, dashboard explanations, capability support, grievance responses, and clear information about how their evidence affected the pathway. Upward extraction without downward return is prohibited. 77.2.8 The doctrine is direct: **Community Evidence is governance evidence. It must be admitted, protected, contextualized, returned, and allowed to correct technical, financial, public authority, platform, and machine-readable records.** *** ### **77.3 Community Observatories** 77.3.1 Community Observatories are locally rooted observability functions through which communities, local institutions, schools, clinics, cooperatives, utilities, neighbourhood groups, Indigenous or local custodians where applicable, community networks, and Competence Cells may observe, record, validate, and communicate local risk, resilience, environmental change, public service conditions, social trust, and early warning signals. 77.3.2 Community Observatories are not surveillance systems. They must not be designed to monitor communities for external control, policing, insurance exclusion, finance scoring, migration enforcement, employer discipline, political targeting, or commercial extraction. Their purpose is public-good resilience, local truth, safeguards, and community correction. 77.3.3 A Community Observatory may operate with advanced tools, low-tech tools, or both. It may use sensors, mobile reports, paper logs, community maps, oral reporting, SMS, radio, public notice boards, local meetings, water gauges, heat logs, biodiversity diaries, utility outage reports, air-quality monitors, community health observations, or field verification. Platform sophistication is not a condition of observatory validity. 77.3.4 Community Observatory records should identify host or custodian, geography, local mandate, observation methods, data classes, publication classes, protected knowledge restrictions, public authority relevance, sensor quality where applicable, attribution rules, community validation, accessibility and language supports, public-safe output rules, and correction route. 77.3.5 Community Observatories must be locally governed. External technical actors, universities, donors, sponsors, public authorities, platforms, or finance actors may support them, but support must not become control. Community observatory design must include local custody, local review, local benefit, local correction, and exit or portability rights. 77.3.6 Community Observatories must be connected carefully to national, regional, and planetary observatory systems. Public-safe summaries, aggregates, metadata, proof receipts, or controlled-room outputs may travel upward, but raw or sensitive community data must not be extracted where local custody, protected knowledge, data sovereignty, or safety require restriction. 77.3.7 Community Observatories must include correction and challenge. If a sensor is wrong, a map is unsafe, a dashboard misstates local conditions, a public authority summary ignores local reports, or an AI system misclassifies local signals, the community observatory must have authority to trigger correction. 77.3.8 The doctrine is direct: **Community Observatories make local risk and resilience visible without turning communities into surveillance subjects. They are locally governed truth surfaces for sensing, validating, protecting, communicating, and correcting place-based reality.** *** ### **77.4 Community Data Pathways** 77.4.1 Community Data Pathways are the governed routes through which community-originated data, evidence, signals, records, maps, observations, restrictions, grievances, corrections, and public-safe summaries may move from local custody into local, national, regional, or planetary Nexus systems while preserving purpose, permission, sensitivity, context, and correction. 77.4.2 Community Data Pathways begin with custody. Community data may be held by a community node, local institution, Indigenous or local custodian where applicable, community observatory, Competence Cell, municipal partner, university host, health institution, utility, or national data zone. The pathway must identify who holds the data, who may see it, who may use it, and who may restrict it. 77.4.3 Community Data Pathways must distinguish data from visibility. A community may allow public-safe visibility of a condition without sharing raw data. It may allow aggregate reporting without revealing location. It may allow technical review without finance-reader access. It may allow local dashboard display without national publication. It may allow national learning without AI training. Visibility is not ownership transfer. 77.4.4 Community Data Pathway records should identify source, custodian, lawful or permission basis, purpose, data class, publication class, permitted users, prohibited users, AI-use status, no-training status, no-map status, no-capital-reader status, cross-border limits, retention rules, withdrawal or restriction rights, and correction route. 77.4.5 Community Data Pathways must support no and not-yet states. No-publication, no-map, no-AI, no-training, no-embedding, no-retrieval, no-capital-reader, no-export, custodian-review, local-only, protected attribution, non-consent, and under-review statuses must be valid and enforceable. A data pathway that only moves data forward and cannot stop data is unsafe. 77.4.6 Community Data Pathways must be public-safe by design. Even generalized data may expose vulnerability, location, identity, protected knowledge, health conditions, informal status, livelihood risk, or infrastructure weakness when combined with other layers. Public-safe transformation must consider inference risk. 77.4.7 Community Data Pathways must include return pathways. Data moving upward must produce value moving back: local summaries, risk alerts, corrected maps, training, tools, safer communication, public authority clarification, service improvements where lawful, and correction results. Data flow without reciprocal return is extraction. 77.4.8 The doctrine is direct: **Community Data Pathways allow community truth to inform the Rail without being extracted by it. Data may travel only with custody, permission, purpose, restriction, public-safe transformation, return value, and correction.** *** ### **77.5 Local Warning Signals** 77.5.1 Local Warning Signals are community-originated indicators of emerging risk, harm, stress, exclusion, infrastructure failure, ecological change, public trust breakdown, public authority confusion, safeguards failure, misinformation, violence risk, health concern, cyber-physical disruption, or living-system change that may require attention before formal data systems detect the issue. 77.5.2 Local Warning Signals may include repeated water pressure drops, unusual illness clusters, heat distress, animal behaviour, blocked drainage, smoke patterns, worker reports, unusual digital outages, misinformation spread, public authority rumours, fear of retaliation, increased conflict around land, service interruptions, contamination concerns, crop stress, migration pressure, community distrust, or sudden changes in local ecology. 77.5.3 Local Warning Signals must be treated as signals, not final determinations. A signal may be uncertain, incomplete, contested, or sensitive. It should trigger classification, validation, safeguards review, public authority capacity review where appropriate, observatory cross-check, and public-safe communication review. It should not automatically become public warning, emergency declaration, or dashboard alarm unless authority and evidence support it. 77.5.4 Local Warning Signal records should identify signal source, place, date, urgency, sensitivity, attribution preference, public authority relevance, safeguards relevance, evidence status, validation need, publication class, immediate containment if needed, escalation route, and correction route. 77.5.5 Local Warning Signals must support degraded-mode pathways. In emergencies or low-connectivity settings, warning signals may travel through radio, SMS, paper forms, community runners, local meetings, public notice boards, schools, clinics, faith institutions, or mesh networks. The Rail must not depend only on digital reporting. 77.5.6 Local Warning Signals must protect sources. A person reporting contamination, violence risk, worker exposure, corruption, public authority confusion, sponsor pressure, community conflict, or protected knowledge exposure may face retaliation. Source protection and non-retaliation must be part of warning-signal governance. 77.5.7 Local Warning Signals must be correction-linked. False signals, misunderstood signals, late signals, ignored signals, or over-amplified signals must be reviewed. The goal is not only response but learning: better baselines, better dashboards, better community routes, better public-safe communication, and better trust. 77.5.8 The doctrine is direct: **Local Warning Signals are early truth from the edge. They must be easy to report, safe to report, carefully validated, public-safe, and capable of triggering escalation without becoming unsupported public authority action.** *** ### **77.6 Community-Owned Governance Artifacts** 77.6.1 Community-Owned Governance Artifacts are the records, maps, protocols, dashboards, registers, warnings, stories, evidence logs, knowledge restrictions, local baselines, grievance records, correction notices, community data rules, public-safe summaries, and observatory outputs that are created by, held by, or governed under the authority of a community, community node, local institution, or protected custodian. 77.6.2 Community-Owned Governance Artifacts may include community risk maps, no-map registers, heat logs, flood memory records, community sensing registers, protected knowledge restrictions, local priority lists, safe-route records, grievance summaries, local warning protocols, public-safe notice templates, local-language explanations, benefit-sharing records, consent and non-consent records, and community correction logs. 77.6.3 Community ownership does not always mean private property ownership in a formal legal sense. It means that governance authority over use, interpretation, access, attribution, publication, restriction, correction, and withdrawal is held locally according to the recorded community, institutional, cultural, legal, or custodial arrangement. 77.6.4 Community-Owned Governance Artifact records should identify artifact type, community or custodian, local authority basis, permitted uses, prohibited uses, publication class, data class, attribution rules, translation rules, AI-use restrictions, finance-reader restrictions, public authority relevance, copying limits, retention rules, and correction route. 77.6.5 Community-Owned Governance Artifacts must not be absorbed into national, regional, or global systems as if they were ordinary data. Higher-level systems may reference, summarize, or receive public-safe versions only according to permission, sensitivity, and purpose. The existence of an artifact does not create a right of extraction. 77.6.6 Community-Owned Governance Artifacts must be protected from institutional appropriation. Donors, universities, platforms, public authorities, sponsors, consultants, and technical assistance teams may help produce or digitize artifacts, but they may not rebrand them, publish them, monetize them, train AI on them, use them for finance-readiness, or claim ownership without permission. 77.6.7 Community-Owned Governance Artifacts must remain correctable by their custodians. If a map becomes unsafe, a local term is mistranslated, a record is misused, an attribution becomes dangerous, or a public-safe summary distorts meaning, the community or custodian must be able to restrict, correct, supersede, or withdraw the artifact or its dependent representation. 77.6.8 The doctrine is direct: **Community-Owned Governance Artifacts are not raw material for the Rail. They are locally governed objects whose use depends on permission, sensitivity, attribution, public-safe transformation, and correction by the community or custodian that holds them.** *** ### **77.7 Anti-Extraction Controls** 77.7.1 Anti-Extraction Controls are the safeguards, records, permissions, publication classes, data-zone rules, benefit-return duties, role limits, and correction mechanisms that prevent community participation, community evidence, community data, local knowledge, protected knowledge, maps, images, stories, vulnerability records, and observatory outputs from being taken for external value without local authority, protection, reciprocity, or correction. 77.7.2 Extraction may occur through research, donor reporting, finance-readiness, AI training, dashboard publication, media storytelling, consulting reports, academic publication, platform analytics, insurance modelling, biodiversity or carbon markets, public authority narratives, sponsor branding, or technical assistance outputs. Public-good language does not excuse extraction. 77.7.3 Anti-Extraction Control records should identify material at risk, source community or custodian, intended use, permitted use, prohibited use, benefit return, access limits, publication class, AI-use status, finance-reader status, attribution rules, withdrawal rights, and correction route. 77.7.4 Anti-Extraction Controls must include purpose limitation. Information shared for a grievance must not become a dashboard layer. Information shared for safety must not become donor marketing. Information shared for local validation must not become finance-reader evidence. Information shared for public authority learning must not become public disclosure without review. 77.7.5 Anti-Extraction Controls must include benefit return. Where community participation or data supports a pathway, the community should receive practical value: safer warnings, better records, corrected public authority language, local training, accessible summaries, improved dashboards, tools, capacity, or enforceable safeguards. “Acknowledgement” alone is insufficient where material value is extracted. 77.7.6 Anti-Extraction Controls must include AI and platform restrictions. Community materials must not be used for training, embedding, retrieval, inference, translation, summarization, or analytics beyond recorded permission. Platform operators must not reuse community data for product development, profiling, benchmarking, or monetization outside permitted purpose. 77.7.7 Anti-Extraction Controls must include enforcement. Misuse may require takedown, access revocation, public-safe correction, proof-pack supersession, donor-report correction, dashboard restriction, model exclusion, benefit remediation, or referral to lawful authority where appropriate. 77.7.8 The doctrine is direct: **Anti-Extraction Controls ensure that community participation does not become a pipeline for data, stories, maps, legitimacy, finance narratives, or platform value. Public-good governance must return value and respect refusal.** *** ### **77.8 Retaliation Risk** 77.8.1 Retaliation Risk is the risk that a person, group, community node, worker, local institution, knowledge holder, public official, expert, journalist, civil society actor, or participant may suffer harm, exclusion, intimidation, job loss, service denial, political pressure, social sanction, legal threat, violence, reputational attack, funding loss, or access restriction because they contributed evidence, dissented, refused, reported harm, raised a grievance, or requested correction. 77.8.2 Retaliation Risk is especially serious in contexts involving employers, utilities, landlords, landowners, armed actors, public authority pressure, corruption, infrastructure failures, industrial sites, extractive projects, public health concerns, protected knowledge, gendered harm, migration status, informal settlements, political conflict, or sponsor influence. Community participation is not protected merely because it is invited. 77.8.3 Retaliation Risk records should identify risk type, affected participant class, source protection need, attribution preference, publication class, non-retaliation measures, safe channel, escalation route, safeguarding function, public authority relevance, interim hold, and correction route. Where recording detail creates danger, the record should capture protective effect without exposing identity. 77.8.4 Retaliation Risk must shape participation design. Separate sessions, confidential intake, anonymous reporting, protected attribution, intermediaries, community custodians, off-platform submission, low-tech channels, delayed publication, aggregation, or non-public validation may be required. A public workshop is not safe participation where retaliation risk exists. 77.8.5 Retaliation Risk must shape evidence handling. A report from a worker, tenant, community member, official, or knowledge holder may need restricted access, masked source, controlled-room review, public-safe summary, or safeguards escalation. The Rail must not expose sources by default attribution, metadata, map location, or dashboard detail. 77.8.6 Retaliation Risk must be treated as a validity condition. If people cannot safely object, report, refuse, or correct, the pathway’s claims of community participation, local validation, safeguards clearance, or public-safe communication may be invalid, paused, narrowed, or downgraded. 77.8.7 Retaliation Risk must be monitored after participation. Harm may occur after meetings, publications, dashboard releases, proof-pack circulation, public authority sessions, or media attention. Safeguards must continue beyond the event. 77.8.8 The doctrine is direct: **Retaliation Risk means participation can create danger. The Rail must protect those who speak, refuse, dissent, report, or correct, because community legitimacy is impossible where truth-telling is unsafe.** *** ### **77.9 Community Correction** 77.9.1 Community Correction is the doctrine that communities, local nodes, affected participants, workers, Indigenous or local knowledge holders where applicable, community observatories, civil society actors, and place-based institutions must have accessible, protected, consequential routes to correct records, maps, dashboards, proof packs, public-safe summaries, public authority descriptions, safeguards records, routeability claims, technical assistance outputs, and handoff materials that describe or affect them. 77.9.2 Community Correction may address incorrect place names, unsafe maps, mistranslation, omitted local evidence, false public authority implication, overstated community support, hidden dissent, inaccurate risk baseline, wrong sensor reading, AI misclassification, protected knowledge exposure, inaccessible process, retaliation concern, donor overclaim, sponsor misuse, or finance-readiness misrepresentation. 77.9.3 Community Correction records should identify correction source or protected source class, object under correction, claimed error, publication class, sensitivity, urgency, interim hold if required, reviewer, affected dependencies, outcome, notice given, and closeout. Where source protection is required, the record must protect identity and attribution. 77.9.4 Community Correction must be easy to initiate. A correction route that requires legal language, high-speed internet, English, formal identity, technical literacy, or platform access is insufficient. Community correction should support oral reports, local-language submissions, paper forms, SMS, community node intake, supported participation, and trusted intermediaries. 77.9.5 Community Correction must have status consequence. If a community correction is valid, it may require dashboard update, map restriction, public-safe summary correction, proof-pack revision, routeability hold, maturity downgrade, publication reclassification, public authority clarification, AI-output withdrawal, or handoff notice. Correction must be able to change the record. 77.9.6 Community Correction must not be dismissed as anecdotal where local reality is at issue. A resident’s report of inaccessible shelter, a worker’s report of unsafe facility practice, a community’s correction of a flood map, or a custodian’s objection to a cultural label may be decisive for the relevant record. 77.9.7 Community Correction must close the loop. The correcting party or protected intermediary should receive an accessible response explaining whether the correction was accepted, partially accepted, deferred, rejected, escalated, or requires additional review, subject to safety and publication class. 77.9.8 The doctrine is direct: **Community Correction is the right of place to correct the system that names it. A Nexus record is not trustworthy if the community it describes cannot challenge and change it.** *** ### **77.10 Community Network Records** 77.10.1 Community Network Records are the official records through which community-run networks, community observatories, community data pathways, local warning systems, community-owned governance artifacts, anti-extraction controls, retaliation safeguards, community correction, community participation, and local network governance become visible, protected, reviewable, and correctionable within Planetary Nexus Governance. 77.10.2 Community Network Records may include community node records, community observatory records, community data custody records, community sensing logs, local warning records, no-map records, protected knowledge records, local dashboard records, community network infrastructure records, public-safe communication records, grievance and correction records, anti-retaliation records, benefit-return records, training records, and escalation records. 77.10.3 Community Network Records should identify community or node, host or custodian, local governance basis, geography, language, accessibility needs, network purpose, data classes, publication classes, role keys, public authority interface, safeguards status, protected knowledge restrictions, technical dependencies, low-tech pathways, escalation routes, and correction routes. 77.10.4 Community Network Records must be sensitivity-first. They may contain information about vulnerable participants, protected knowledge, informal systems, local conflict, health concerns, infrastructure weakness, worker reports, retaliation risk, or sensitive locations. The record must protect the community before it serves interoperability. 77.10.5 Community Network Records must distinguish community network function from public authority function. A community warning signal is not an official emergency order. A community dashboard is not a regulatory determination. A community observatory report is not public authority approval. Public authority boundaries must remain clear. 77.10.6 Community Network Records must include ownership and permission rules. Community-generated artifacts, data, maps, and reports must carry permitted uses, prohibited uses, attribution rules, AI restrictions, finance-reader restrictions, publication limits, and withdrawal or correction rights. 77.10.7 Community Network Records must support upward and downward integration. Local records may feed national and regional systems where safe, and national or regional corrections must return to local systems where relevant. Community network records must not become one-way extraction. 77.10.8 The doctrine is direct: **Community Network Records make community-run governance infrastructure visible without exposing it. They preserve local custody, sensitivity, permissions, public authority boundaries, safeguards, benefit return, and correction.** *** ### **77.11 Community Networks as Intelligence and Resilience Infrastructure** 77.11.1 Community Networks are intelligence and resilience infrastructure because they carry forms of truth and continuity that formal systems often miss. They can sense early risk, validate maps, correct dashboards, maintain communication during outages, identify accessibility barriers, support local warning, preserve protected knowledge, route grievances, and maintain trust under stress. 77.11.2 Community Networks may include mesh networks, local radio, SMS trees, mutual aid networks, community observatories, neighbourhood committees, local data stewards, trusted institutions, schools, clinics, cooperatives, faith institutions, Indigenous or local governance structures where applicable, youth networks, disability organizations, worker networks, and local media. Their technical form may vary; their governance role is local continuity and truth. 77.11.3 Community Networks must not be romanticized as substitutes for public services or public authority duties. They are resilience infrastructure, not abandonment infrastructure. Their existence must not justify withdrawal of public services, underfunding, emergency neglect, or shifting state duties onto unpaid local actors. 77.11.4 Community Networks must be supported without control. Public authorities, donors, sponsors, universities, platforms, and technical actors may support equipment, training, connectivity, accessibility, translation, safety, and maintenance. They may not convert community networks into surveillance, political mobilization tools, finance pipelines, donor branding surfaces, or vendor dependency. 77.11.5 Community Networks must include degraded-mode continuity. Their value is greatest when formal systems fail: power outages, floods, wildfire smoke, cyber disruption, public health emergencies, communications outages, conflict, or platform failure. Paper routes, offline records, radio, community runners, local notice boards, and manual procedures may be as important as digital tools. 77.11.6 Community Networks must be connected to the Rail through respectful interfaces. They should be able to send signals, receive public-safe information, submit corrections, protect knowledge, escalate warnings, and participate in national or regional observability without surrendering custody or being overwhelmed by reporting burden. 77.11.7 Community Networks must be protected from overload. Community-run systems often operate with limited resources and volunteer labour. The Rail must not impose excessive reporting, complex forms, constant meetings, donor metrics, or platform administration on community networks. Support must reduce burden. 77.11.8 The doctrine is direct: **Community Networks are public-good intelligence and resilience infrastructure at the edge of the Rail. They make governance more truthful, continuous, local, and humane, but they must be supported without extraction, overload, surveillance, or substitution for public duties.** *** ### **77.12 Community Participation as Protected Record** 77.12.1 Community Participation as Protected Record is the final doctrine of this chapter. It states that community participation must be treated as a sensitive governance record, not as public relations, meeting attendance, donor output, consent evidence, photographic proof, platform engagement metric, or legitimacy token. Participation is meaningful only when its capacity, limits, safety, dissent, accessibility, and correction are recorded. 77.12.2 Protected participation records should identify who participated or what participant class participated where safe, in what capacity, through what method, in what language, with what accessibility support, under what safeguards, with what information, with what ability to refuse, with what dissent, with what unresolved concerns, with what public claims permitted, and with what correction route. 77.12.3 Community Participation as Protected Record requires careful attribution. Some participation may be public. Some may be confidential. Some may be aggregated. Some may be represented through protected intermediaries. Some should not be publicly named. Photographs, attendance lists, quotes, video recordings, maps, and social media posts can create harm and must be governed by permission and publication class. 77.12.4 Participation records must distinguish attendance, awareness, input, validation, non-objection, consent, dissent, objection, refusal, and protected non-participation. These are different states. The Rail must not collapse them into “community engaged.” 77.12.5 Participation records must be claims-linked. A public statement that a pathway is community-informed, locally validated, community-supported, community-led, culturally safe, or rights-aligned must be supported by participation records that permit that exact claim. If participation was limited, contested, inaccessible, unsafe, or preliminary, the public claim must say so or not be made. 77.12.6 Participation records must be correctionable. A participant, community node, custodian, or protected intermediary must be able to correct how participation was represented, withdraw attribution, restrict a quote, challenge translation, report retaliation, clarify dissent, or request reclassification of the participation record where permitted. 77.12.7 Participation records must affect maturity and routeability. A pathway cannot claim safeguards validity, community legitimacy, public-safe release, local validation, or finance-readiness if the participation record shows inaccessible process, unresolved dissent, retaliation risk, misrepresentation, protected knowledge concerns, or non-consent that remains unresolved. 77.12.8 The final doctrine is direct: **Community Legitimacy and Community-Run Networks make the Rail answerable to the edge. Community participation, evidence, observatories, data pathways, warning signals, artifacts, networks, and corrections are protected governance records. They are not symbols of legitimacy; they are conditions of legitimacy. Planetary Nexus Governance becomes trustworthy only when communities can safely sense, speak, refuse, protect, govern, and correct the systems that claim to serve them.** --- # 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/xiii.-architecture/77.-community-networks.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.