> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/organization/architecture/ii.-definitions/vi.-nexus-node.md).

# VI. Nexus Node

### 2.6 Nexus Observatory Node

The **Nexus Observatory Node** defines the local operating unit of [Nexus Observatory](/organization/organization/architecture/ii.-definitions/iv.-nexus-observatory.md) within the [Nexus Ecosystem](/organization/organization/architecture/ii.-definitions/i.-nexus-ecosystem.md). It acts as **digital public infrastructure** for **distributed observability**, **local risk intelligence**, **AI-RAN**, **DePIN**, **sovereign compute**, **edge evidence**, and **public-safe reporting**.

Nexus Observatory Node connects [Nexus Network](/organization/organization/architecture/ii.-definitions/ii.-nexus-network.md), [Nexus Observatory Protocol](/organization/organization/architecture/ii.-definitions/v.-nexus-protocol.md), [Nexus Hub](/organization/organization/architecture/ii.-definitions/vii.-nexus-hub.md), [Nexus Cluster](/organization/organization/architecture/ii.-definitions/viii.-nexus-cluster.md), [Nexus Hotspot](/organization/organization/architecture/ii.-definitions/ix.-nexus-hotspot.md), [Regional Cluster](/organization/organization/architecture/ii.-definitions/x.-regional-cluster.md), [National Dense Nexus Core](/organization/organization/architecture/ii.-definitions/xi.-nexus-core.md), [Nexus Standards](/organization/organization/architecture/ii.-definitions/xii.-nexus-standards.md), [Nexus Truth Engine](/organization/organization/architecture/ii.-definitions/xiv.-nexus-truth-engine.md), [Nexus Rails](/organization/organization/architecture/ii.-definitions/xv.-nexus-rails.md), and [Nexus Academy](/organization/organization/architecture/ii.-definitions/xxiii.-nexus-academy.md).

**2.6.1 Definition.** **Nexus Observatory Node** means a local, site-based, institutional, infrastructure, community, sectoral, public authority-adjacent, academic, enterprise, or hybrid evidence anchor within [Nexus Observatory](/organization/organization/architecture/ii.-definitions/iv.-nexus-observatory.md) and [Nexus Network](/organization/organization/architecture/ii.-definitions/ii.-nexus-network.md). It is the bounded operating unit through which signals from a real-world context are sensed, collected, governed, validated, classified, routed, public-safe translated, finance-readiness prepared where applicable, and corrected under [Nexus Observatory Protocol](/organization/organization/architecture/ii.-definitions/v.-nexus-protocol.md).

A Nexus Observatory Node may be physical, digital, or hybrid. It may include sensors, reference sensors, AI-RAN connectivity, O-RAN components, private wireless, non-terrestrial backhaul, edge compute, sovereign compute interfaces, DePIN-compatible devices, telemetry systems, cyber logs, geospatial tools, digital twins, dashboards, controlled data rooms, host records, provider records, public authority capacity records, community safeguard records, Academy learning records, proof receipts, role keys, smart licenses, and clean-exit records.

A Nexus Observatory Node is not merely a sensor site, hotspot, lab, dashboard, pilot, router, server rack, data room, campus project, field station, demonstration, DePIN device, AI-RAN installation, or local partnership. It may contain any of those elements, but its Nexus meaning arises only when it is governed as a record-based, standards-readable, public-safe, finance-bounded, community-protective, provider-neutral, and correctionable evidence unit.

A Node is the local place where Nexus becomes observable. It is where global doctrine meets physical evidence, regional risk meets local context, national mandate meets host readiness, and public-good meaning meets operational reality.

**2.6.2 Constitutional Position.** A Nexus Observatory Node shall be interpreted under the Nexus Constitutional Framework, the Nexus Master Architecture Whitepaper, the Public-Good Stack Framework Charter, the One Rail / Two Stacks Doctrine, the Validity-by-Record Doctrine, the Correctionability Doctrine, the Non-Execution Doctrine, the Verifiable Compute and Verifiable Intelligence Doctrine, the Nexus Observatory Charter, and the Nexus Observatory Protocol.

A Node is not a public authority, regulator, emergency command post, public warning system, certification body, procurement approval site, finance approval site, insurance approval site, legal compliance finding, professional accreditation, public infrastructure adoption, investment product, or sovereign decision. It may support public authority learning, emergency-support evidence, finance-readiness materials, public-safe dashboards, provider demonstrations, host readiness, community safeguards, and Project SPV preparation, but it does not itself execute the decisions reserved to lawful actors.

A Node’s constitutional role is to localize observability without localizing overclaim. It allows a specific site, institution, corridor, facility, community, watershed, utility, hospital, port, campus, data center, remote area, or infrastructure system to produce Nexus-compatible evidence without implying that the site has been certified, adopted, financed, procured, publicly endorsed, or made mature beyond the record.

**2.6.3 Core Thesis.** Nexus Observatory Nodes exist because systemic risk is ultimately encountered locally. Floods occur in watersheds and streets. Heat affects buildings, hospitals, schools, and communities. Cyber-physical risk appears in ports, utilities, telecom systems, hospitals, data centers, and industrial sites. Food risk is experienced through farms, warehouses, cold chains, markets, schools, hospitals, and logistics routes. Biodiversity risk appears in wetlands, forests, fisheries, corridors, soils, species habitats, and community stewardship areas. Energy risk appears at substations, microgrids, data centers, water pumps, towers, and critical facilities. AI-RAN, DePIN, sovereign compute, and edge AI must be tested somewhere before they can be trusted anywhere.

A Nexus Observatory Node turns local observation into governed evidence. It prevents local pilots from becoming unsupported claims. It prevents local dashboards from becoming false authority. It prevents local public authority attendance from becoming endorsement. It prevents local community knowledge from becoming extractive data. It prevents provider installations from becoming procurement shortcuts. It prevents sponsor support from becoming control. It prevents local evidence from becoming finance-readiness without review. It prevents a working demonstration from being mistaken for maturity.

The Node is therefore the smallest complete Nexus evidence unit: local enough to be real, governed enough to be trusted, and connected enough to support regional, national, and global learning.

**2.6.4 Strategic Ambition.** The strategic ambition of the Nexus Observatory Node is to create a globally interoperable class of local evidence anchors that can support systemic-risk observability, exponential-technology validation, public-safe reporting, finance-readiness, Academy learning, Project SPV preparation, and correction across countries and sectors.

Nodes should allow the Nexus Ecosystem to scale without losing local fidelity. A wildfire corridor Node, hospital resilience Node, water-quality Node, remote community Node, port Node, utility Node, biodiversity Node, campus Node, sovereign compute Node, AI-RAN Node, DePIN Node, cyber range Node, or food cold-chain Node may each operate in different contexts, but all should share the same public-good grammar: identity, host readiness, source lineage, standards profile, proof receipts, data classification, cyber controls, AI-use controls, community safeguards, public authority boundaries, public-safe claims, finance-readiness limits, lifecycle control, clean exit, and correction.

The ambition is not to create a universal hardware box. It is to create a universal governance and evidence pattern for local observability.

**2.6.5 Whole-System Purpose.** A Nexus Observatory Node performs ten whole-system functions.

a) It **anchors local evidence** by connecting physical, digital, institutional, public authority, community, environmental, infrastructure, and operational signals to a governed Nexus record.

b) It **creates observability** through sensors, telemetry, AI-RAN, DePIN-compatible devices, geospatial layers, cyber logs, host systems, community observations, provider systems, and public authority context where lawful.

c) It **governs data** through lawful basis, data rights, purpose limitation, classification, access control, AI-use restrictions, retention, deletion, sealing, archival, and clean exit.

d) It **forms evidence objects** and telemetry objects with source lineage, provenance, method, custody, confidence, uncertainty, limitations, public-safe status, standards relevance, maturity relevance, finance-readiness relevance, and correction path.

e) It **activates standards** through the Nexus Standards sequence of Trigger → Obligation → Profile → Check → Proof Receipt → Correction.

f) It **routes review** to Nexus Truth Engine, Nexus Docket, Nexus Grid, Nexus Rails, Nexus Academy, Nexus Competence Cells, public authority rooms, controlled data rooms, or Project SPV readiness pathways where applicable.

g) It **supports local learning** for operators, hosts, providers, communities, Academy participants, public authority learners, technical stewards, cyber teams, data stewards, and finance-readiness readers.

h) It **supports public-safe reporting** through controlled dashboards, maps, summaries, public pages, annual outputs, correction notices, and controlled derivatives.

i) It **supports deployment preparation** by generating host readiness records, provider scope records, lifecycle records, finance-readiness inputs, insurance-readiness questions, SPV-readiness inputs, and clean-exit plans.

j) It **maintains correctionability** through versioning, amendment, supersession, suspension, withdrawal, downgrade, re-entry, retirement, archival, and propagation to derivatives.

**2.6.6 Node Scope.** A Nexus Observatory Node may operate at the scale of a facility, campus, community, watershed site, utility system, hospital, port, airport, rail site, data center, remote community, wildfire corridor segment, flood basin, energy system, food logistics site, biodiversity site, research lab, public authority facility, industrial site, telecom site, field station, cyber range, Academy lab, or Project SPV asset.

The Node’s scope must be recorded. Scope should identify what the Node observes, what it does not observe, what data it may collect, what data it may not collect, what public-safe outputs it may produce, what public claims are permitted, what authority references are permitted, what finance-readiness use is permitted, what provider claims are prohibited, what sponsor references are permitted, what community safeguards apply, and what correction path governs.

A Node without clear scope should not support public claims, maturity review, finance-readiness, public authority references, or deployment statements.

**2.6.7 Node Categories.** Nexus Observatory Nodes may be classified by function, context, or maturity. Categories may include:

a) **Evidence Nodes**, focused on sensing, telemetry, evidence formation, and public-safe reporting;

b) **AI-RAN Nodes**, focused on AI-RAN connectivity, radio-wave sensing, telemetry, edge inference, degraded-mode communications, and network evidence;

c) **DePIN Nodes**, focused on physically validated decentralized infrastructure participation;

d) **Sovereign Compute Nodes**, focused on secure processing, data residency, compute-to-data, local inference, controlled data handling, and national dense core interfaces;

e) **Cyber Nodes**, focused on cyber observability, cyber range activity, OT/IIoT evidence, incident learning, and cyber-sensitive records;

f) **Geospatial Nodes**, focused on GIS, Earth observation, public-safe maps, digital twins, remote sensing, and map-harm controls;

g) **Water Nodes**, focused on hydrology, water quality, flood, drought, watershed intelligence, utility continuity, and water-related public-safe reporting;

h) **Energy Nodes**, focused on microgrids, backup power, grid-edge evidence, data center energy, critical continuity, and energy resilience;

i) **Food Nodes**, focused on agriculture, cold chain, logistics, nutrition continuity, water dependence, energy dependence, and supply continuity;

j) **Health Nodes**, focused on hospital continuity, public health-sensitive data boundaries, degraded communications, energy-water-health dependencies, and care infrastructure;

k) **Biodiversity Nodes**, focused on habitat, species, ecosystem services, protected knowledge, restoration integrity, and public-safe geospatial controls;

l) **Academy Nodes**, focused on training, competence formation, operator literacy, public authority literacy, and safeguards learning;

m) **SPV-Ready Nodes**, focused on asset-level deployment preparation, lifecycle cost, host readiness, provider scope, insurance-readiness, and finance-readiness inputs.

A Node may have more than one category, but each category must be recorded and bounded.

**2.6.8 Node Admission.** A proposed Nexus Observatory Node should not be treated as a Node merely because a host, provider, sponsor, public authority, community, university, company, or consortium describes it as one. Node admission requires a recorded intake process.

Node intake should identify host, site, purpose, risk domain, technology domain, proposed scope, responsible steward, provider involvement, sponsor involvement, public authority involvement, community context, data rights, AI-use intentions, cyber posture, equipment, connectivity, compute, sensors, maps, dashboards, intended public outputs, finance-readiness relevance, SPV relevance, Academy relevance, lifecycle obligations, and clean-exit plan.

A proposed Node may be recorded as proposed, candidate, under intake, provisionally scoped, Docketed, active within limited scope, suspended, withdrawn, retired, archived, or re-entered. These states must remain distinct. Proposed status is not active status. Candidate status is not maturity. Active status is not certification.

**2.6.9 Node Identity.** Every Nexus Observatory Node must have a recorded Node identity. Node identity should include official name, node identifier, host name, steward, location or geography at the appropriate public-safe precision, category, scope, status, version, responsible institution, governing instrument, source-document references, public-safe claims permissions, Docket status where applicable, Grid status where applicable, Rails relevance where applicable, Academy relevance where applicable, and correction record.

Node identity must not be confused with public authority approval, public infrastructure status, procurement status, certification, finance approval, insurance approval, or deployment authorization.

The Node’s name and identifier must be controlled to prevent unauthorized forks, misleading derivatives, or false public claims.

**2.6.10 Host Readiness.** A Node requires host readiness. Host readiness means that the host has recorded authority, site permission, access control, safety arrangements, equipment custody, data rights, cyber requirements, power, connectivity, environmental conditions, insurance review where applicable, community context where applicable, public authority context where applicable, provider access, serviceability plan, lifecycle obligations, public claims rules, and clean-exit duties.

A host may be a university, laboratory, hospital, utility, port, airport, rail operator, public building, data center, community institution, public authority facility, private facility, infrastructure owner, regional hub, national company, Project SPV, or other lawful site holder.

Host participation does not create adoption, public authority endorsement, procurement approval, maturity, finance-readiness, provider preference, community consent, public-good ownership, or permanent infrastructure status beyond the record.

**2.6.11 Stewardship.** Every Node must have a steward or stewarding arrangement. Stewardship may be held by a public-good institution, consortium, host, national company, Project SPV, university, laboratory, qualified operator, or other lawful actor within recorded scope.

The steward is responsible for record integrity, scope control, standards routing, public-safe claims control, data classification, AI-use discipline, cybersecurity coordination, provider coordination, sponsor reference control, host interface, community safeguards where applicable, public authority boundary control, evidence routing, correction, lifecycle control, and clean exit.

Stewardship does not create ownership of public-good meaning. A steward administers the Node record; the steward does not become the authority to widen Nexus claims beyond the record.

**2.6.12 Node Governance Record.** Each Node should maintain a Node Governance Record. The record should include:

a) Node identity;

b) host readiness record;

c) steward record;

d) provider scope record;

e) sponsor record where applicable;

f) public authority capacity record where applicable;

g) community safeguards record where applicable;

h) data governance record;

i) AI-use record;

j) cyber posture record;

k) equipment and asset register;

l) sensor and telemetry register;

m) model and software register;

n) standards profile;

o) proof receipt register;

p) Docket and Grid routing record where applicable;

q) Rails relevance record where applicable;

r) public-safe publication permissions;

s) lifecycle and serviceability record;

t) clean-exit record;

u) correction history.

The Node Governance Record is the source of truth for Node meaning.

**2.6.13 Equipment and Asset Register.** Each Node should maintain an equipment and asset register where physical or digital assets are used. The register should record equipment type, serial or identifier where appropriate, owner, custodian, provider, host location, installation date, purpose, configuration state, firmware or software version where relevant, calibration state where relevant, cybersecurity status, warranty status, insurance relevance, serviceability requirements, energy requirements, connectivity requirements, data generated, public-safe limits, removal conditions, disposal conditions, and correction history.

Equipment presence is not maturity. A sensor installed at a Node is not evidence by itself. A radio installed at a Node is not telecom approval. A server installed at a Node is not sovereign compute approval. A DePIN device installed at a Node is not validated infrastructure unless the record supports that state.

**2.6.14 Connectivity and AI-RAN.** A Node may use AI-RAN, O-RAN, private wireless, non-terrestrial networks, satellite backhaul, mesh networks, wired networks, or other connectivity. Connectivity must be recorded by provider, architecture, scope, spectrum context where relevant, cyber posture, data flows, telemetry types, public-safe outputs, degraded-mode role, serviceability, and correction path.

AI-RAN-enabled Nodes may support radio-wave sensing, edge inference, telemetry, public-safe dashboards, critical infrastructure monitoring, remote community connectivity, hospital continuity, utility monitoring, wildfire corridors, flood systems, and national dense core synchronization.

AI-RAN participation at a Node does not imply telecom approval, spectrum authorization, public authority endorsement, public warning authority, emergency command, procurement status, provider preference, safety certification, finance-readiness approval, or permanent infrastructure status.

**2.6.15 Compute and Edge Processing.** A Node may include edge compute, local AI inference, secure processing, GPU or accelerator resources, secure enclaves, confidential computing, compute-to-data environments, or interfaces to regional clusters and national dense cores.

Compute records should identify compute owner, provider, host, workload type, data classes, model use, access control, cyber posture, energy requirements, cooling requirements, data residency requirements, export-control considerations where relevant, sanctions considerations where relevant, lifecycle refresh, public authority data restrictions where applicable, and clean exit.

Compute at a Node does not create sovereign compute status, public authority approval, procurement approval, public finance approval, investment approval, legal compliance, provider preference, or finance-readiness by itself.

**2.6.16 Sensor and Telemetry Layer.** A Node may include sensors, reference sensors, cameras where lawful, meters, environmental sensors, water sensors, air sensors, structural sensors, energy sensors, cyber telemetry, utility telemetry, hospital continuity telemetry, port telemetry, agricultural telemetry, biodiversity monitoring devices, AI-RAN telemetry, DePIN telemetry, robotics outputs, drone imagery, and manual observation records.

Every material sensor or telemetry stream should have source identity, method, calibration state where applicable, custody, data classification, rights, cyber posture, validation state, public-safe status, confidence, uncertainty, standards relevance, and correction path.

Telemetry is not truth by default. Telemetry becomes evidence only when governed.

**2.6.17 DePIN Compatibility.** A Node may include DePIN-compatible devices or networks where distributed physical infrastructure can contribute physically validated, identity-bound, standards-aligned, public-safe, and correctionable evidence.

DePIN participation at a Node should record device identity, custody, location at public-safe precision, host context, provider scope, telemetry type, validation method, anti-spoofing status, anti-fork status, incentive-risk review, data rights, cyber posture, standards profile, proof receipts, public-safe limits, and correction path.

A DePIN device, hotspot, token reference, ledger record, device count, or network map does not by itself create evidence validity, maturity, finance-readiness, public authority approval, community consent, or infrastructure readiness.

**2.6.18 Geospatial and Mapping Layer.** A Node may produce or support geospatial evidence, GIS layers, exposure maps, hazard maps, public-safe maps, infrastructure maps, biodiversity maps, watershed maps, digital twin inputs, satellite analysis, remote sensing outputs, and local context maps.

Geospatial outputs must be governed through source lineage, date, method, resolution, precision, uncertainty, public-safe status, protected knowledge controls, community safeguards, infrastructure sensitivity, cyber sensitivity, public authority boundaries, finance-readiness limits, and correction path.

A Node map is not an official determination, public warning, land-use decision, environmental permit, emergency instruction, insurance conclusion, finance approval, procurement approval, or public authority finding.

**2.6.19 Digital Twin Layer.** A Node may support digital twins or simulations for infrastructure stress, climate scenarios, cyber-physical interactions, energy-water-compute dependencies, hospital continuity, port operations, wildfire corridors, flood resilience, utility performance, remote community logistics, sovereign compute load, AI-RAN network states, DePIN telemetry, or SPV-readiness assumptions.

Digital twin outputs must preserve assumptions, time horizon, geography, data sources, limitations, uncertainty, public-safe status, standards relevance, review status, and correction path.

A Node digital twin is not direct observation, official prediction, engineering certification, public authority determination, finance approval, procurement approval, insurance conclusion, or guarantee.

**2.6.20 Cybersecurity Layer.** A Node requires cybersecurity controls proportional to its risk. Controls may include identity and access management, zero trust, privileged access control, encryption, logging, monitoring, vulnerability management, patching, incident response, backups, recovery, secure enclaves, secure development, supplier review, device identity, credential rotation, breach escalation, cyber-sensitive evidence classification, and secure decommissioning.

A Node cyber incident may trigger evidence limitation, credential revocation, proof receipt suspension, public-safe publication restriction, provider review, host review, Docket correction, Grid correction, Rails update, data-room closure, public authority notice where appropriate, community notice where appropriate, or stop-the-line escalation.

Cybersecurity is part of Node validity. It is not an IT appendix.

**2.6.21 Data Governance.** A Node shall treat data as governed material. Data may include sensor data, AI-RAN telemetry, DePIN records, cyber logs, infrastructure telemetry, geospatial layers, digital twin inputs, public authority context, community context, health-sensitive data, infrastructure-sensitive data, finance-sensitive evidence, commercially sensitive records, personal information, research participant data, protected knowledge, model outputs, AI prompts, AI outputs, embeddings, retrieval indexes, and public-safe derivatives.

Node data governance must include lawful basis, purpose limitation, minimization, proportionality, classification, access control, retention, deletion, sealing, archival, public-safe extraction, sovereign data controls where applicable, cross-border transfer controls where applicable, AI-use restrictions, cybersecurity controls, public authority rules, community safeguards, and clean exit.

Node data shall not become sponsor material, provider marketing, AI-training material, finance narrative, public dashboard content, research output, or public claim by default.

**2.6.22 AI Governance.** A Node may use AI for classification, anomaly detection, summarization, translation, scenario generation, cyber review, public-safe drafting, evidence triage, geospatial interpretation, digital twin operation, finance-readiness organization, dashboard support, model evaluation, and controlled derivative production.

AI use at a Node must be governed through model identity, model version, AI-use register, model register, training restrictions, retrieval controls, embedding controls, inference limits, fine-tuning controls, prompt and output records, hallucination review, human review where required, agentic tool limits, output correction, model retirement, and public-safe publication review.

AI at a Node does not become truth, public authority decision, legal advice, investment advice, insurance conclusion, procurement decision, maturity, recognition, public finance approval, provider qualification, emergency command, public warning, or official Nexus status.

**2.6.23 Public Authority Interface.** A Node may include public authority participation where lawful and appropriate. Public authority participants may be official representatives, observers, technical experts, regulator-listening participants, public finance readers, public infrastructure operators, emergency-management participants, public health participants, academic representatives, personal-capacity participants, non-attributable participants, or controlled-room participants.

Every public authority interface at a Node must record capacity, purpose, attribution rules, confidentiality level, public statement permissions, name-use limits, logo-use limits, data rights, public-safe output limits, and correction path.

Public authority participation at a Node does not imply endorsement, adoption, procurement approval, regulatory approval, funding approval, public finance approval, public warning authority, emergency command, public health order, infrastructure approval, sovereign obligation, treaty position, PPP approval, official policy, or national infrastructure adoption unless separately and expressly recorded by the competent authority.

**2.6.24 Community Interface.** A Node may include community observations, local knowledge, Indigenous and local knowledge where permissioned, protected environmental knowledge, accessibility review, language access, safeguards review, public-safe mapping review, benefit/risk review, grievance pathways, remedy pathways, and correction pathways.

Community participation at a Node must not be treated as unrestricted consent, data transfer, public authority approval, sponsor endorsement, provider endorsement, deployment approval, public-good legitimacy, finance-readiness proof, or unrestricted publication permission.

Where community knowledge, protected knowledge, sensitive geospatial context, vulnerable-population information, health-sensitive information, water knowledge, biodiversity knowledge, cultural knowledge, or local risk knowledge is involved, the Node shall apply permission, non-attribution, public-safe mapping, access restriction, AI-use restriction, publication limits, withdrawal, sealing, grievance, remedy, and correction where appropriate.

**2.6.25 Protected Knowledge.** A Node may encounter protected knowledge, including Indigenous, local, territorial, cultural, environmental, biodiversity-related, water-related, health-sensitive, vulnerable-population, infrastructure-sensitive, security-sensitive, public authority-sensitive, community-held, or otherwise protected knowledge.

Protected knowledge at a Node must be classified, permissioned where required, access-controlled, publication-limited, AI-restricted, public-safe, withdrawal-aware, grievance-aware, remedy-aware, and correctionable.

Protected knowledge shall not be converted into unrestricted maps, dashboards, AI training data, finance-readiness narratives, sponsor materials, provider marketing, public claims, or deployment authorization without recorded permission and safeguards.

**2.6.26 Standards Profile.** Every active Node should have a standards profile. The standards profile should identify applicable Nexus Standards, triggers, obligations, checks, proof receipts, review intervals, public-safe publication conditions, correction triggers, suspension conditions, re-entry conditions, retirement conditions, and clean-exit requirements.

A Node standards profile may cover data governance, AI use, cyber controls, sensor calibration, AI-RAN validation, DePIN validation, public authority participation, community safeguards, protected knowledge, geospatial publication, public-safe dashboards, provider scope, sponsor references, finance-readiness use, Docket routing, Grid relevance, and Rails relevance.

The standards profile is not legal compliance, certification, procurement approval, or public authority approval. It is the Node’s Nexus operating discipline.

**2.6.27 Proof Receipts.** A Node may produce or support proof receipts for defined checks, methods, validations, reviews, calibrations, data classifications, cyber reviews, AI-use reviews, public-safe reviews, geospatial reviews, protected knowledge handling, host readiness reviews, provider scope reviews, DePIN validation, AI-RAN validation, compute attestation, clean-exit actions, and correction actions.

A proof receipt records that a defined act occurred within a defined scope. It does not certify safety, legality, performance, compliance, financeability, insurability, procurement readiness, public authority approval, community consent, provider competence, or maturity beyond the recorded scope.

Proof receipts must remain versioned, bounded, and correctionable.

**2.6.28 Proof of Competence.** A Node may support proof-of-competence records for node operators, AI-RAN technicians, DePIN operators, cyber stewards, data stewards, public-safe publishers, geospatial analysts, model stewards, Academy participants, provider teams, host teams, community stewards, and SPV planners.

Proof of competence may record training, supervised practice, exercise completion, technical review, evidence handling, standards literacy, cybersecurity literacy, AI-use literacy, public-safe reporting literacy, or field operations readiness.

Proof of competence is not professional licensure, certification, employment qualification, procurement qualification, provider qualification, public authority approval, or Grid maturity unless separately authorized and recorded.

**2.6.29 Evidence Routing.** A Node routes evidence to the appropriate Nexus pathways. Evidence may be routed to Nexus Truth Engine for corroboration, Nexus Standards for checks, Nexus Docket for structured review, Nexus Grid for maturity relevance where applicable, Nexus Rails for finance-readiness relevance, Nexus Academy for learning, Nexus Competence Cells for expert review, public authority rooms for capacity-aware learning, controlled data rooms for restricted review, or Project SPV pathways for deployment preparation.

Routing does not equal approval. Routing means the record has entered the correct review pathway.

**2.6.30 Docket Relationship.** Node records may be routed to Nexus Docket when evidence, claims, public-safe outputs, maturity questions, public authority references, provider claims, sponsor claims, community safeguards, finance-readiness materials, or correction items require structured review.

Docket activity may produce review notes, evidence requests, deferrals, correction flags, route recommendations, withdrawal, archival, or Grid review candidates.

Docket status is not approval, adoption, certification, procurement approval, finance approval, insurance approval, public authority endorsement, provider selection, public warning, or maturity beyond the record.

**2.6.31 Grid Relationship.** A Node may become Grid-relevant or Grid-recorded only through authorized review. Grid may record bounded maturity states for Nodes, Node components, Node outputs, Node public-safe dashboards, Node maps, Node evidence systems, or Node-related programs where permitted.

Grid maturity requires evidence, scope, standards relevance, review, limitations, public-safe claims permission, correction history, downgrade rules, suspension rules, renewal logic, and archival pathway.

A Node is not Grid-mature because it is installed, active, sponsored, publicized, demonstrated, benchmarked, attended by public authorities, connected to AI-RAN, ledger-anchored, or used in Nexus Universe.

**2.6.32 Rails Relationship.** A Node may support Nexus Rails by generating finance-readiness inputs for RNFD, NFD, UNFD, proof packs, diligence gap maps, insurance-readiness summaries, public finance learning notes, or SPV-readiness materials.

Node finance-readiness inputs may include host readiness, provider scope, lifecycle cost, data rights, cyber posture, AI-use controls, evidence quality, public authority capacity, community safeguards, standards profile, proof receipts, unresolved gaps, and correction history.

Node Rails relevance does not create investment advice, insurance advice, underwriting, rating, guarantee, creditworthiness, bankability, public finance approval, procurement approval, lender commitment, insurer commitment, investor commitment, or capital commitment.

**2.6.33 Academy Relationship.** A Node may support Nexus Academy as a local learning environment. Academy activity at a Node may include operator training, AI-RAN training, DePIN training, cyber exercises, data stewardship training, public-safe reporting training, public authority literacy, community safeguards literacy, finance-readiness literacy, geospatial literacy, evidence literacy, and clean-exit practice.

Academy activity at a Node may generate learning records and competence records. It does not create professional licensure, certification, provider qualification, procurement qualification, employment qualification, public authority approval, Docket status, Grid status, or finance-readiness status unless separately authorized and recorded.

**2.6.34 Competence Cell Relationship.** A Node may request or require Competence Cell review for high-consequence, disputed, sensitive, technical, or unclear matters. Competence Cells may review AI-RAN outputs, DePIN validation, cyber-sensitive records, geospatial precision, digital twin assumptions, water-quality evidence, climate scenarios, hospital continuity evidence, biodiversity data, protected knowledge restrictions, sovereign compute records, model outputs, robotics data, finance-readiness evidence, public authority capacity, and correction needs.

Competence Cell review strengthens interpretation. It does not replace public authorities, regulators, courts, licensed professionals, procurement bodies, investors, insurers, engineers, clinicians, environmental authorities, or formal certification bodies unless separately and lawfully authorized.

**2.6.35 Public-Safe Reporting.** A Node may produce public-safe reports, dashboards, maps, summaries, evidence extracts, maturity summaries, benchmark summaries, finance-readiness extracts, Academy outputs, public authority summaries, community-safeguards summaries, correction notices, and controlled derivatives.

Public-safe reporting from a Node must avoid unsupported claims of certification, endorsement, public authority approval, procurement approval, investment approval, financeability, insurability, underwriting, funding commitment, official warning, emergency authority, Grid admission, preferred-provider status, scientific consensus beyond record, community consent beyond recorded scope, sovereign approval, or technology maturity beyond evidence.

Every public Node claim must be record-based, scope-limited, limitation-aware, authority-safe, finance-safe, procurement-safe, provider-neutral, sponsor-safe, community-safe, data-safe, cyber-safe, uncertainty-aware, and correctionable.

**2.6.36 Node Dashboards.** A Node dashboard is a governed public-safe or controlled-room derivative. It should identify source, date, method, update frequency, evidence state, limitations, public-safe status, audience, authority boundary, finance boundary, data classification, cyber sensitivity, public authority capacity where relevant, community safeguard where relevant, and correction path.

A Node dashboard is not official status, public warning, emergency command, regulatory finding, procurement approval, finance approval, insurance conclusion, certification, or maturity unless the governing record separately supports that meaning.

A stale dashboard is a correction risk and should be updated, restricted, retired, or marked accordingly.

**2.6.37 Node Maps.** Node maps are governed geospatial outputs. A map should identify source, date, method, resolution, precision, uncertainty, limitations, public-safe status, protected knowledge controls, community safeguards, public authority boundary, cyber sensitivity, infrastructure sensitivity, finance-readiness limits, and correction path.

A Node map is not an official determination, public warning, land-use decision, environmental permit, emergency instruction, insurance conclusion, finance approval, procurement approval, or public authority finding.

Map harm prevention is a Node requirement. Sensitive species, sacred sites, vulnerable communities, infrastructure vulnerabilities, cyber weaknesses, protected environmental knowledge, health-sensitive context, or security-sensitive locations may require masking, aggregation, delay, restricted layers, non-attribution, omission, or sealing.

**2.6.38 Node Public Claims.** Public claims about a Node must be controlled. A Node may be described only according to its recorded status, scope, evidence basis, maturity state where applicable, public-safe claims permission, host record, provider record, sponsor record, public authority capacity record, community safeguard record, and correction state.

No actor may represent a Node as certified, approved, adopted, finance-ready, insured, public-authority-endorsed, procurement-approved, sovereign-approved, Grid-mature, provider-preferred, community-approved, or permanent infrastructure unless the governing record expressly supports that meaning.

Node claims must remain versioned, dated, scope-limited, and correctionable.

**2.6.39 Provider Participation.** Providers may participate in a Node by supplying sensors, AI-RAN, O-RAN, private wireless, satellite backhaul, DePIN devices, sovereign compute components, edge systems, dashboards, software, secure enclaves, data-room tools, cyber systems, digital twins, geospatial tools, robotics, drones, field operations, calibration services, maintenance, lifecycle support, identity systems, model evaluation tools, assurance tooling, and managed services.

Provider participation must be governed by recorded scope, cybersecurity duties, data duties, AI-use duties, public claims rules, public authority reference limits, sponsor relationship disclosures, conflict controls, performance review, suspension pathways, requalification pathways, and clean exit.

Provider participation at a Node does not create preferred-provider status, procurement advantage, certification, public authority approval, finance approval, or control over public-good outputs.

**2.6.40 Sponsor Participation.** Sponsors may support a Node through funding, grants, equipment, compute, cloud credits, software, facilities, services, staff time, data-room support, labs, scholarships, public-safe reporting support, Nexus Universe support, Academy support, or other in-kind contributions.

Sponsor support may strengthen Node capacity, but it does not purchase governance, evidence interpretation, recognition, maturity, Docket outcome, Grid outcome, standards influence, provider preference, public authority access, finance-readiness influence, public-safe reporting control, Academy credential influence, community endorsement, or correction outcomes.

Sponsor references must remain record-based, scope-limited, benefit-schedule-consistent, public-safe, and correctionable.

**2.6.41 Investor and Insurer Interface.** A Node may support investor, insurer, lender, MDB, DFI, public finance actor, or capital-reader learning through controlled review of evidence, host readiness, provider scope, lifecycle cost, risk, insurance-readiness questions, public finance learning, SPV-readiness inputs, proof packs, or diligence gap maps.

Review does not mean interest. Questions do not mean diligence acceptance. Attendance does not mean commitment. Proof packs are not offering materials. Node finance-readiness outputs are not investment advice, insurance submissions, credit opinions, ratings, guarantees, bankability certifications, public finance approvals, or capital commitments.

**2.6.42 Project SPV Relationship.** A Node may support Project SPV preparation where the Node or related assets may become part of an asset-level deployment pathway. SPV-related Node records may include host readiness, site rights, asset register, provider scope, lifecycle cost, serviceability, insurance-readiness questions, data rights, cyber posture, public authority capacity, community safeguards, public-safe claims, revenue logic where lawful, public-good support obligations, and clean-exit duties.

A Node does not become an SPV merely because it is finance-relevant. A Node may generate SPV-readiness evidence, but SPV formation, investment, contracting, procurement, insurance, public finance, and deployment require separate lawful instruments and decisions.

**2.6.43 Competition and Procurement Neutrality.** Node activity shall preserve competition, antitrust, and procurement neutrality. A Node may involve multiple providers, sponsors, public authorities, hosts, national companies, SPVs, investors, insurers, universities, and laboratories for public-good learning and evidence formation.

It shall not be used to coordinate prices, bids, territories, customers, wages, rates, premiums, underwriting positions, credit terms, procurement strategies, market allocation, exclusion, commercial boycotts, provider preference, or collective commercial conduct.

Node records may inform lawful procurement, but they are not procurement. Provider participation is not procurement qualification. Proof receipts are not tender acceptance. Docket review is not approval. Grid maturity is not award.

**2.6.44 Regulated-Perimeter Discipline.** Node activity shall respect securities, investment adviser, broker-dealer, lending, insurance, underwriting, rating, public finance, tax, procurement, antitrust, sanctions, export-control, national security, fiduciary, privacy, cybersecurity, health, environmental, professional, and public authority boundaries.

A Node may organize evidence and learning across these areas, but it does not eliminate the need for lawful actors to make their own decisions under applicable law, mandate, license, fiduciary duty, procurement rule, regulatory process, or professional obligation.

**2.6.45 Sanctions and Controlled Technology.** A Node shall not become a channel for restricted technology transfer, sanctions evasion, unlawful dual-use activity, uncontrolled compute access, cyber misuse, sensitive geospatial disclosure, drone misuse, AI model misuse, protected knowledge exposure, public authority data misuse, or unsafe public claims.

Node activity involving advanced AI, compute, GPUs, cyber tools, telecom systems, AI-RAN, O-RAN, non-terrestrial networks, robotics, drones, geospatial intelligence, cryptography, controlled datasets, public authority information, health-sensitive information, infrastructure-sensitive records, or protected knowledge may require screening, classification, controlled-room rules, access limits, public-safe extraction, stop-the-line escalation, correction, withdrawal, sealing, or clean exit.

**2.6.46 Lifecycle Control.** A Node requires lifecycle control for equipment, sensors, radios, compute, software, models, dashboards, maps, data rooms, cyber ranges, proof systems, role keys, smart licenses, AI systems, APIs, telemetry feeds, provider systems, host systems, public-safe outputs, and controlled derivatives.

Lifecycle control includes installation, operation, maintenance, calibration, update, patching, credential rotation, model review, drift review, refresh, replacement, suspension, revocation, retirement, archival, disposal, redeployment, deletion, sealing, correction, and clean exit.

A Node that cannot be maintained should not be treated as mature. A sensor that cannot be calibrated should not support high-confidence evidence. A model that cannot be retired should not support public-safe outputs. A dashboard that cannot be updated should not be public.

**2.6.47 Clean Exit.** Every Node must have a clean-exit pathway. Clean exit should address equipment, cloud, compute, credentials, access, data, AI artifacts, embeddings, retrieval indexes, models, logs, licenses, telemetry, public claims, host obligations, provider obligations, sponsor references, Docket status, Grid status, public-safe records, finance-readiness records, public authority references, community records, and correction obligations.

Clean exit may result in retirement, transfer, renewal, conversion to permanent infrastructure, SPV transfer where lawful, equipment return, donation, purchase, secure disposal, data deletion, data sealing, archival, dashboard retirement, map update, public claim withdrawal, role-key revocation, smart-license closeout, and final correction notices.

Failure to plan clean exit is a Node readiness defect.

**2.6.48 Correctionability.** A Node must remain correctionable at every material point.

A Node record, sensor record, telemetry object, evidence object, proof receipt, AI output, dashboard, map, Docket note, Grid note, finance-readiness input, Academy record, sponsor reference, provider reference, public authority summary, host record, community record, geospatial layer, digital twin output, DePIN record, AI-RAN result, sovereign compute record, cyber record, or public-safe report may be corrected, superseded, withdrawn, suspended, downgraded, archived, or re-entered.

Correction may be triggered by error, new evidence, changed law, changed data rights, changed public authority capacity, cyber incident, model drift, AI hallucination, sensor drift, calibration failure, DePIN spoofing, AI-RAN signal limitation, geospatial harm, community permission change, protected knowledge concern, sponsor overclaim, provider overclaim, finance-readiness overclaim, public-safe risk, or public-good integrity concern.

Correction must propagate to controlled derivatives where relevant.

**2.6.49 Stop-the-Line Authority.** A Node shall include stop-the-line authority. Stop-the-line authority may pause evidence publication, restrict dashboards, remove maps, seal data rooms, revoke credentials, suspend proof receipts, stop provider activity, restrict AI use, halt public claims, suspend public authority references, pause finance-readiness outputs, require additional review, or trigger correction.

Stop-the-line may be invoked for public safety, cyber risk, data misuse, AI-use risk, public authority overclaim, community harm, finance-readiness overclaim, legal risk, competition risk, sanctions risk, export-control risk, protected knowledge exposure, infrastructure-control risk, map harm, public-safe publication risk, or public-good integrity risk.

Stop-the-line authority is not failure. It is the Node’s integrity protection mechanism.

**2.6.50 Node Versioning.** A Node must be versioned. Node versioning should identify status, effective date, scope, equipment state, software state, standards profile, proof receipt state, data governance state, AI-use state, cyber posture, provider scope, host readiness, public authority capacity, community safeguards, public-safe publication permissions, correction history, and superseded versions.

Versioning prevents silent drift. A Node that changes hardware, software, data use, AI model, provider, host condition, public authority role, community permission, cyber posture, dashboard, map, or public-safe claim should update its Node record.

**2.6.51 Controlled Derivatives.** Node information may be explained through diagrams, dashboards, maps, reports, web pages, public summaries, benchmark summaries, country materials, regional materials, investor materials, provider materials, sponsor materials, host materials, public authority briefings, AI-readable summaries, translations, videos, and visualizations.

These controlled derivatives may simplify, but they must not expand. They must preserve official names, role separation, non-execution, public authority non-endorsement, finance-readiness non-reliance, provider neutrality, support-without-control, recognition-is-not-certification, proof-receipt-is-not-guarantee, public-safe-reporting-is-not-public-warning, Docket-is-review-not-approval, Grid-is-maturity-record-not-certification, version date, correction status, and source-document hierarchy.

**2.6.52 Source-Document Control.** A Node shall be interpreted under the Nexus source-document family and its own Node Governance Record. Node reports, dashboards, maps, decks, public pages, sponsor materials, provider materials, public authority summaries, investor materials, AI summaries, translations, benchmark summaries, challenge outputs, and controlled derivatives shall not widen or contradict governing source documents.

Where a controlled derivative conflicts with a governing source document or Node Governance Record, the governing record controls. Where an AI summary widens meaning, the source record controls. Where a dashboard becomes stale, the corrected record controls. Where a proof receipt is narrowed, public claims must narrow.

**2.6.53 Validity by Record.** A Node operates under validity by record.

No claim of Node status, Node maturity, evidence validity, telemetry validity, proof receipt, role permission, device identity, AI-RAN result, DePIN result, sovereign compute result, cyber result, digital twin result, map status, dashboard status, public-safe output, provider status, host readiness, sponsor role, public authority participation, finance-readiness input, Docket route, Grid status, Academy record, or controlled derivative is valid merely because asserted.

Validity requires records, provenance, scope, responsible stewardship, review state, limitations, maturity state where applicable, public-safe claims permission, correction history, and interpretive context.

A statement that cannot be traced to a record should not be treated as Node meaning.

**2.6.54 Minimum Truthfulness.** Every statement made under or about a Node must satisfy minimum truthfulness. It must be record-based, maturity-accurate, scope-limited, authority-safe, finance-safe, procurement-safe, public-safe, uncertainty-aware, provider-neutral, sponsor-safe, community-safe, cyber-safe, data-safe, and correctionable.

It must avoid borrowed maturity, symbolic localization, implied commitment, false capital signals, certification overclaim, provider preference, public authority overclaim, emergency-command confusion, public-warning confusion, AI-as-truth overclaim, ledger-as-truth overclaim, finance-readiness overclaim, sponsor-control implication, community-consent overclaim, procurement overclaim, map harm, data extraction, and maturity inflation.

If a statement cannot be traced, bounded, limited, and corrected, it should not be made.

**2.6.55 Failure Modes.** Nexus Observatory Nodes are designed to prevent local observability failures, including:

a) a local sensor installation being mistaken for validated evidence;

b) a local dashboard being mistaken for official status;

c) a local map being mistaken for public authority determination;

d) an AI-RAN test being mistaken for telecom approval or emergency authority;

e) a DePIN device count being mistaken for validated infrastructure;

f) a provider installation being mistaken for procurement approval;

g) sponsor support being mistaken for influence;

h) public authority attendance being mistaken for endorsement;

i) community participation being mistaken for unrestricted consent;

j) AI outputs being mistaken for verified intelligence;

k) digital twins being mistaken for predictions;

l) ledger anchors being mistaken for physical-world proof;

m) cyber-sensitive records being treated as public-safe;

n) protected knowledge being exposed through maps, dashboards, AI systems, or finance materials;

o) host readiness being assumed rather than recorded;

p) finance-readiness being claimed without evidence, lifecycle cost, host readiness, provider scope, and correction history;

q) equipment, sensors, dashboards, maps, role keys, data rooms, AI artifacts, cloud accounts, or public claims becoming orphaned after use.

These failure modes are the reason a Node must be governed as a Nexus evidence unit rather than treated as a local pilot.

**2.6.56 Strategic Effect.** The strategic effect of a Nexus Observatory Node is that local reality becomes part of the Nexus public-good rail without becoming overclaimed.

A Node allows a hospital, watershed, port, utility, campus, community, corridor, data center, remote site, biodiversity area, cyber range, or infrastructure system to contribute evidence that is structured, standards-readable, public-safe, finance-readable where appropriate, and correctionable. It enables local learning to inform regional legitimacy, national mandate, Project SPV preparation, and global public-good knowledge.

It turns local deployment into institutional memory. It turns local evidence into reviewable evidence. It turns local technology into bounded technology. It turns local public authority participation into capacity-classified learning. It turns local community knowledge into protected context. It turns local finance-readiness into disciplined review material. It turns local claims into correctable records.

**2.6.57 Summary Rule.** A Nexus Observatory Node is the local evidence anchor of Nexus Observatory and Nexus Network. It is the bounded unit through which a real-world site, host, system, community, institution, or infrastructure context can sense, record, validate, classify, route, publish safely, finance-readiness prepare where applicable, and correct evidence under Nexus Observatory Protocol.

A Node is not a certificate, public authority approval, procurement approval, public warning, finance approval, insurance approval, provider preference, sponsor entitlement, community consent, sovereign approval, or maturity state by default. It becomes Nexus-relevant only through records, host readiness, standards profiles, evidence objects, telemetry objects, proof receipts, public-safe claims permission, data governance, AI governance, cybersecurity, community safeguards, lifecycle control, clean exit, and correction.

**2.6.58 Final Thesis.** Nexus Observatory Node is where Nexus becomes real in place. It is the local, governed, public-good evidence anchor that allows systemic risk and exponential technology to be observed without being overclaimed, tested without being self-validating, displayed without becoming public warning, financed-readiness prepared without becoming finance execution, and deployed toward lawful pathways without collapsing public-good meaning into enterprise activity.

Its power lies in disciplined localization: local evidence without local overclaim; local technology without vendor capture; local public authority participation without endorsement; local community knowledge without extraction; local dashboards without false status; local maps without harm; local AI without truth inflation; local DePIN without unverifiable legitimacy; local AI-RAN without telecom hype; local finance-readiness without financial execution; and local deployment preparation without false maturity.

A Nexus Observatory Node is the smallest complete operating unit of the Nexus evidence architecture and the foundation from which hubs, clusters, regional clusters, national dense cores, Project SPVs, and the permanent Nexus Network can learn, scale, correct, and renew.

**2.6.59 Concise Summary.** Nexus Observatory Node is the local evidence anchor of Nexus. It turns site-based signals, systems, and context into governed evidence that can support standards, review, public-safe reporting, readiness, and correction. Its role is to make local observability usable without turning a local deployment into false authority.

**2.6.60 Next Steps.** Read [Nexus Observatory](/organization/organization/architecture/ii.-definitions/iv.-nexus-observatory.md) for the wider evidence layer and [Nexus Observatory Protocol](/organization/organization/architecture/ii.-definitions/v.-nexus-protocol.md) for the rules that govern Nodes. Then continue to [Nexus Hub](/organization/organization/architecture/ii.-definitions/vii.-nexus-hub.md), [Nexus Cluster](/organization/organization/architecture/ii.-definitions/viii.-nexus-cluster.md), and [Nexus Standards](/organization/organization/architecture/ii.-definitions/xii.-nexus-standards.md) to follow how local evidence scales and is controlled.

**2.6.61 Related Topics.** Use these pages to move through the closest connected layers of the Node.

* **Core context:** [Nexus Ecosystem](/organization/organization/architecture/ii.-definitions/i.-nexus-ecosystem.md), [Nexus Network](/organization/organization/architecture/ii.-definitions/ii.-nexus-network.md), and [Nexus Observatory](/organization/organization/architecture/ii.-definitions/iv.-nexus-observatory.md)
* **Protocol and control:** [Nexus Observatory Protocol](/organization/organization/architecture/ii.-definitions/v.-nexus-protocol.md), [Nexus Standards](/organization/organization/architecture/ii.-definitions/xii.-nexus-standards.md), and [Nexus Truth Engine](/organization/organization/architecture/ii.-definitions/xiv.-nexus-truth-engine.md)
* **Scaling layers:** [Nexus Hub](/organization/organization/architecture/ii.-definitions/vii.-nexus-hub.md), [Nexus Cluster](/organization/organization/architecture/ii.-definitions/viii.-nexus-cluster.md), and [Regional Cluster](/organization/organization/architecture/ii.-definitions/x.-regional-cluster.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/organization/architecture/ii.-definitions/vi.-nexus-node.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.