# 40. Baselines

### **40.1 Baseline Definition**

40.1.1 A Baseline is the recorded reference state against which change, risk, performance, maturity, impact, readiness, safeguards, technical adequacy, ecological condition, social condition, public authority capacity, data quality, and correction are assessed within the Nexus Rail. It is the disciplined “before,” “current,” or “reference” condition that makes observation, comparison, verification, routeability, and accountability possible.

40.1.2 Baselines exist because governance cannot responsibly claim improvement, degradation, compliance, resilience, readiness, risk reduction, maturity, or impact without knowing the reference state. A resilience project cannot show value without a baseline. A data-centre pathway cannot be assessed without energy, water, compute, grid, community, cyber, land, and public authority baselines. A biodiversity pathway cannot be governed without ecological baseline. A public-safe dashboard cannot display change without a defined reference. A proof pack cannot be routeable without baseline truth.

40.1.3 A Baseline is not a static fact frozen forever. It is a governed reference object. It has source, scope, method, date, version, data class, uncertainty, authority, limitations, public-safe status, review cycle, challenge route, correction path, and supersession rule. It may be technical, ecological, social, community, financial, readiness-related, public authority-related, sensor-based, data-based, model-based, or composite.

40.1.4 Baselines may be created at many levels: local, community, site, municipal, watershed, corridor, basin, ecosystem, subnational, national, regional, sectoral, institutional, platform, technical, and global. A local baseline may show lived service failure. A national baseline may show sovereign data-zone maturity. A regional baseline may show cross-border water stress. A technical baseline may show minimum acceptable system conditions. A financial-readiness baseline may show evidence required before routeability.

40.1.5 Baselines must distinguish reference from approval. A baseline may identify existing conditions or required conditions. It does not approve a project, certify a system, create public authority authorization, confirm community consent, endorse a provider, or declare finance-readiness unless a competent function separately issues such status. A baseline is a reference object, not a governance outcome by itself.

40.1.6 Baselines must remain plural and contextual. A single baseline rarely captures the whole system. A water pathway may require hydrological, ecological, public authority, community, infrastructure, financial, technical, and sensor baselines. A cyber-resilience pathway may require network, identity, logging, incident, governance, and human-capacity baselines. Compound risk requires baseline constellations, not one-dimensional reference points.

40.1.7 The doctrine is direct:

**A Baseline is a governed reference state that allows the Rail to measure change, risk, readiness, maturity, impact, and correction without mistaking comparison for approval, or reference for authority.**

***

### **40.2 Technical Baselines**

40.2.1 Technical Baselines are recorded reference conditions for technologies, infrastructure systems, software, platforms, data systems, AI systems, compute environments, sensors, networks, industrial systems, energy systems, cyber controls, digital twins, APIs, schemas, dashboards, repositories, release pipelines, and other technical assets within or connected to the Nexus Rail.

40.2.2 Technical Baselines are necessary because high-consequence systems cannot be governed by verbal assurance. A platform must have access-control baseline. A model must have documentation and evaluation baseline. A data centre must have energy, water, cyber, physical security, resilience, and sovereign data baseline. A sensor network must have calibration and provenance baseline. A public-good software release must have security, dependency, license, and provenance baseline. A dashboard must have lineage and public-claims baseline.

40.2.3 A Technical Baseline should identify the system, configuration, version, architecture, operating environment, applicable standards, performance criteria, security controls, data flows, dependencies, access rules, release state, testing method, TMD review status, known limitations, maintenance requirements, and correction triggers. It should state what the baseline supports and what it does not support.

40.2.4 Technical Baselines may be minimum baselines, reference baselines, current-state baselines, target-state baselines, release baselines, verification baselines, incident baselines, or maturity baselines. A minimum baseline sets required conditions for a given use. A reference baseline provides guidance. A current-state baseline records present reality. A target-state baseline defines a desired future condition. These must not be confused.

40.2.5 Technical Baselines must be TMD-aware. Where technical consequence is high, the appropriate Technical Management Division should define, review, or validate the baseline. General management, platform administrators, vendors, sponsors, or consultants should not unilaterally define baselines that carry governance effect.

40.2.6 Technical Baselines must avoid vendor capture. A baseline should not be written to privilege one platform, provider, cloud, model, sensor, equipment vendor, or proprietary architecture unless the record justifies the choice and procurement neutrality is preserved. Public-good baselines should support interoperability, portability, security, and no-bypass discipline.

40.2.7 Technical Baselines must be claims-disciplined. Meeting a technical baseline may mean a system is fit for a defined technical purpose. It does not mean the system is legally approved, publicly endorsed, safe in all contexts, finance-ready, procurement-selected, community-accepted, or free of future risk.

40.2.8 The doctrine is direct:

**Technical Baselines make technical systems governable by recording the conditions against which performance, security, interoperability, maturity, release, and correction can be assessed within scope.**

***

### **40.3 Ecological Baselines**

40.3.1 Ecological Baselines are recorded reference conditions for living systems, natural systems, ecosystems, watersheds, biodiversity, land, soil, air, water, climate exposure, species, habitats, ecosystem services, ecological thresholds, environmental health, and human–nature interactions relevant to Nexus Governance.

40.3.2 Ecological Baselines are necessary because development, resilience, technology, energy, compute, infrastructure, industrial, food, health, and finance pathways often claim benefit while shifting ecological burden. Without ecological baseline, the Rail cannot know whether a pathway protects, harms, restores, degrades, or merely relocates risk.

40.3.3 An Ecological Baseline should identify the ecological system, geography or protected-location class, time period, data sources, method, seasonal conditions, historical context, uncertainty, protected knowledge restrictions, public authority relevance, community knowledge, Indigenous or local knowledge where applicable and permitted, monitoring indicators, thresholds, stressors, and correction triggers.

40.3.4 Ecological Baselines should be multi-scalar. A site-level baseline may show local water stress. A basin baseline may show upstream-downstream dynamics. A regional baseline may show biodiversity corridors. A national baseline may show climate exposure. A global baseline may show planetary pattern. Each scale has different meaning and limitation.

40.3.5 Ecological Baselines must include living-system dynamics. Nature is not a fixed background condition. Water availability changes seasonally. Biodiversity shifts. Fire regimes change. Heat extremes intensify. Disease ecologies move. Land use changes. Baselines must therefore be time-aware and reviewable.

40.3.6 Ecological Baselines must protect sensitive locations and knowledge. Protected species, sacred sites, cultural landscapes, water sources, restoration areas, community resources, or vulnerable ecosystems may require masking, aggregation, controlled access, or non-public treatment. Public-safe mapping is required.

40.3.7 Ecological Baselines must constrain routeability and readiness. A pathway that appears technically or financially attractive may be blocked, conditioned, or re-scoped if ecological baseline shows unacceptable water stress, biodiversity loss, community dependency, climate exposure, or cumulative harm. Ecological reality is not an optional annex.

40.3.8 The doctrine is direct:

**Ecological Baselines ensure that the Rail measures human and technological action against living-system reality, making nature a constraint, signal, and correction source rather than a decorative category.**

***

### **40.4 Social and Community Baselines**

40.4.1 Social and Community Baselines are recorded reference conditions for lived risk, community wellbeing, public trust, participation capacity, vulnerability, access, equity, service conditions, cultural context, local knowledge, social infrastructure, institutional trust, grievance history, displacement risk, livelihood conditions, and community resilience.

40.4.2 Social and Community Baselines are necessary because technical and ecological evidence alone cannot determine public value. A pathway may reduce technical risk while increasing community burden. A data-centre project may improve compute sovereignty while worsening local water stress or public distrust. A resilience program may appear efficient while excluding vulnerable groups. Social baseline prevents governance from treating people as afterthoughts.

40.4.3 A Social and Community Baseline should identify affected communities, source methods, participation routes, representation limits, vulnerability factors, access conditions, public service realities, local risk perceptions, cultural protocols, existing conflicts, grievance history, protected knowledge, language needs, disability access, trust conditions, and safeguards requirements.

40.4.4 Social and Community Baselines must distinguish participation, consultation, consent, objection, refusal, dissent, protected disclosure, and non-participation. Attendance at a meeting cannot be recorded as support. A workshop cannot be recorded as consent. A silent community cannot be presumed to agree. Baseline records must preserve participation-state truth.

40.4.5 Social and Community Baselines should be community-informed and safeguards-reviewed. External experts may help structure methods, but communities must be able to challenge misrepresentation, supply context, restrict sensitive knowledge, and request correction. Social baseline without community correction is weak.

40.4.6 Social and Community Baselines must include power analysis. Who is heard? Who is excluded? Who controls local institutions? Who may fear retaliation? Who benefits from the pathway? Who bears risk? Who may be displaced? Who controls data? Who can appeal? Public-good governance must begin with power, not only stakeholder lists.

40.4.7 Social and Community Baselines must be updated. Trust changes. Risk changes. Public authority action changes. Community leadership changes. Local harm emerges. Migration, conflict, climate impacts, industrial activity, public service failure, or economic pressure may alter baseline conditions. A stale social baseline can create serious harm.

40.4.8 The doctrine is direct:

**Social and Community Baselines make lived reality visible, ensuring that public value is measured against trust, equity, participation, vulnerability, culture, power, and the ability of communities to correct the record.**

***

### **40.5 Financial and Readiness Baselines**

40.5.1 Financial and Readiness Baselines are recorded reference conditions used to determine whether a pathway, project, program, institution, evidence pack, technical system, or public-value intervention has the minimum evidence, governance, safeguards, public authority, technical, operational, and monitoring conditions required for routeability review or lawful downstream consideration.

40.5.2 These baselines are GRA-relevant but not finance-executing. They do not determine investment suitability, creditworthiness, insurance approval, underwriting, rating, guarantee eligibility, procurement award, public finance approval, or financial return. They define the evidence and governance conditions needed before lawful finance or adoption actors can responsibly conduct their own diligence.

40.5.3 A Financial and Readiness Baseline may include site truth, evidence quality, public authority capacity, safeguards status, ecological constraints, technical baseline status, monitoring plan, operational assumptions, lifecycle cost assumptions, maintenance responsibilities, risk allocation, data-zone controls, incident procedures, correction triggers, and public claims boundaries.

40.5.4 Readiness Baselines must distinguish readiness for different audiences. A pathway may be ready for internal GRA review, but not capital-reader review. It may be ready for grant discussion, but not procurement authority review. It may be ready for public authority learning, but not downstream handoff. It may be ready for technical assistance, but not routeability. Readiness must state the next step.

40.5.5 Financial and Readiness Baselines must include public-value priority. The baseline should ask whether the pathway serves public value, reduces risk, protects communities, respects ecological constraint, preserves public authority boundaries, and supports correction before asking whether it can attract capital. Capital readability is subordinate to public value.

40.5.6 Financial and Readiness Baselines must prevent financialization of evidence. A baseline must not pressure evidence producers to simplify, omit uncertainty, downgrade safeguards, hide dissent, or overstate public authority capacity to make a pathway appear bankable. Finance-readable does not mean finance-shaped.

40.5.7 Financial and Readiness Baselines must be correction-linked. If site conditions change, public authority capacity clarifies, community concerns emerge, technical evidence is superseded, or ecological baseline shifts, readiness must be reviewed. Routeability built on an outdated baseline must be withdrawn or corrected.

40.5.8 The doctrine is direct:

**Financial and Readiness Baselines define the evidence and governance conditions for lawful routeability without turning public-value pathways into investment advice, bankability claims, procurement preferences, or capital-driven narratives.**

***

### **40.6 Public Authority Baselines**

40.6.1 Public Authority Baselines are recorded reference conditions describing the lawful authorities, mandates, capacities, procedures, jurisdictional responsibilities, public decision pathways, emergency roles, procurement authorities, regulatory bodies, public finance actors, municipal functions, Indigenous or territorial governance where applicable, and public-sector interfaces relevant to a matter.

40.6.2 Public Authority Baselines are necessary because public authority confusion is one of the most dangerous sources of overclaim. A ministry may observe but not approve. A regulator may regulate one component but not another. A municipality may control land use but not energy infrastructure. A public finance actor may discuss but not commit funds. A public authority participant may act personally, technically, politically, or officially. The baseline makes capacity visible.

40.6.3 A Public Authority Baseline should identify competent public bodies, jurisdiction, mandate, relevant laws or procedures, decision points, approval requirements, non-approval participation, data rights, reporting obligations, emergency powers, procurement roles, public finance roles, regulatory interfaces, public communication responsibilities, and limitations.

40.6.4 Public Authority Baselines must classify participation capacity. A public actor may participate as observer, learner, data provider, technical contributor, regulator, procurer, funder, emergency authority, policy body, implementation partner, host, or lawful decision-maker. Each capacity must be recorded separately.

40.6.5 Public Authority Baselines must prevent laundering. Nexus records must not imply public authority approval, government endorsement, regulatory clearance, public finance support, procurement status, or emergency instruction unless the competent public authority has lawfully issued that action and the record states it.

40.6.6 Public Authority Baselines must be updated. Governments reorganize. Laws change. Officials change roles. Delegations expire. Public finance priorities shift. Emergency conditions alter authority. A public authority baseline that was accurate last quarter may be misleading today.

40.6.7 Public Authority Baselines must coexist with non-governmental character. Planetary Nexus Governance supports public authorities and records their capacity, but it does not become public authority. Public Authority Baselines protect both public authorities and the Rail from role confusion.

40.6.8 The doctrine is direct:

**Public Authority Baselines make lawful authority visible, ensuring that public-sector participation, learning, data sharing, regulation, procurement, finance, and approval are never confused with one another or borrowed by implication.**

***

### **40.7 Sensor and Data Baselines**

40.7.1 Sensor and Data Baselines are recorded reference conditions for data sources, datasets, telemetry streams, IoT devices, sensor networks, observatory nodes, geospatial layers, satellite products, model inputs, data pipelines, dashboards, metadata systems, and data-quality controls within the Nexus Observatory, Nexus Network, Sovereign Data Zones, and Nexus Platforms.

40.7.2 Sensor and Data Baselines are necessary because data systems can create false confidence. A sensor may be uncalibrated. A dataset may be biased. A satellite layer may be outdated. A dashboard may hide missingness. A telemetry stream may be spoofed. A model input may be incomplete. Without sensor and data baselines, the Rail cannot determine whether data is fit for purpose.

40.7.3 A Sensor Baseline should identify device type, location or protected location class, calibration state, installation date, maintenance schedule, operator, data steward, sampling frequency, accuracy, precision, uptime, known failure modes, cyber posture, provenance, and public-safe status.

40.7.4 A Data Baseline should identify source, steward, collection method, time period, coverage, missingness, quality, bias, sensitivity, rights, publication class, AI-use eligibility, transformations, version, retention, and correction history. It should also state permitted use and prohibited use.

40.7.5 Sensor and Data Baselines must distinguish data availability from evidence adequacy. A large dataset may still be poor evidence if biased, stale, irrelevant, unverified, or unsafe. A sparse dataset may be useful if high-quality and fit for purpose. Data volume is not truth.

40.7.6 Sensor and Data Baselines must include cyber and integrity controls. Data streams may be tampered with, interrupted, manipulated, poisoned, or accessed improperly. Baselines should include authentication, logging, anomaly detection, integrity checks, and incident response proportional to risk.

40.7.7 Sensor and Data Baselines must support public-safe dashboards. A dashboard should display baseline status, gaps, update frequency, uncertainty, and correction status where relevant. It should not display data as current, complete, or verified when baseline conditions do not support that claim.

40.7.8 The doctrine is direct:

**Sensor and Data Baselines determine whether the Rail’s data streams are fit for their intended use, preserving provenance, quality, sensitivity, integrity, and correction before data becomes evidence or public meaning.**

***

### **40.8 Baseline Versioning**

40.8.1 Baseline Versioning is the discipline through which Baselines are assigned versions, effective dates, status labels, source records, change histories, supersession rules, and dependency links. It ensures that actors know which Baseline applied at which time and what changed when a Baseline was updated.

40.8.2 Baseline Versioning is necessary because Baselines evolve. New data arrives. Methods improve. Public authority capacity changes. Ecological conditions shift. Community evidence emerges. Technical standards are updated. Sensor networks are recalibrated. Financial-readiness criteria mature. Without versioning, the Rail cannot know whether a decision relied on current or obsolete reference conditions.

40.8.3 Each material Baseline should have a version identifier, title, scope, status, effective date, adoption or approval authority, review date, source records, method notes, change log, previous version, supersession statement, publication class, and correction pathway. If a Baseline is draft, pilot, provisional, operating, mature, suspended, withdrawn, or superseded, that status must be visible.

40.8.4 Baseline Versioning must support dependency tracking. If a public-safe report, maturity record, proof pack, dashboard, technical finding, or handoff relied on Baseline v1.2, and Baseline v1.3 materially changes the relevant condition, dependent records must be reviewed. Versioning enables correction.

40.8.5 Baseline Versioning must preserve historical interpretability. A decision made under an older Baseline may have been valid at the time. Supersession does not automatically mean prior bad faith. But current reliance must use current Baseline unless the record justifies otherwise.

40.8.6 Versioning must distinguish minor edits from material changes. Typographic corrections, formatting changes, method clarifications, data updates, scope changes, threshold changes, and authority changes have different governance meaning. Material changes may require review, notice, or re-entry.

40.8.7 Baseline Versioning should be machine-readable. Platforms, dashboards, AEPs, proof packs, TMD findings, and registers should be able to reference specific Baseline versions. AI-assisted workflows must not silently use superseded Baselines.

40.8.8 The doctrine is direct:

**Baseline Versioning keeps reference states historically traceable and currently reliable, allowing the Rail to know which Baseline governed each claim, decision, dashboard, proof pack, and correction.**

***

### **40.9 Baseline Challenge**

40.9.1 Baseline Challenge is the process by which actors may question, contest, supplement, correct, or request review of a Baseline. It is the right and discipline that prevents Baselines from becoming unchallengeable technical, institutional, or political truth.

40.9.2 Baseline Challenge is necessary because Baselines can be wrong, incomplete, biased, outdated, overgeneralized, exclusionary, technically weak, socially unsafe, ecologically blind, finance-shaped, or public authority-confused. A community may challenge a social baseline. A TMD may challenge a technical baseline. A public authority may challenge capacity baseline. A local observatory may challenge national data. A safeguards function may challenge public-safe mapping. A finance-readiness function may challenge site-truth assumptions.

40.9.3 A Baseline Challenge should identify the Baseline, version, challenging actor, capacity, affected matter, challenge grounds, evidence offered, urgency, public-safe implications, safeguards concerns, public authority relevance, requested action, and whether immediate hold, correction, or review is requested.

40.9.4 Challenges must be accessible. Communities, Indigenous or local knowledge holders where applicable, public authorities, technical experts, civil society, operators, researchers, Competence Cells, TMDs, and downstream actors should have appropriate routes to challenge Baselines. Challenge must not require elite technical language where lived evidence is relevant.

40.9.5 Challenges must be protected where needed. A person challenging an industrial baseline, public authority baseline, community representation baseline, cyber baseline, or protected knowledge baseline may face retaliation or risk. Confidential and safeguards-protected challenge routes must exist.

40.9.6 Baseline Challenge must not automatically invalidate a Baseline. A challenge may trigger review, limitation, public-safe note, safeguards hold, TMD review, data re-check, community validation, public authority clarification, or no change with reasons. The challenge disposition must be recorded.

40.9.7 Baseline Challenge must support re-entry. If a Baseline is corrected, dependent AEPs, dashboards, proof packs, maturity records, routeability states, public-safe reports, and handoff records may need review. Challenge is not complete until its dependency effects are considered.

40.9.8 The doctrine is direct:

**Baseline Challenge ensures that reference states remain accountable to evidence, communities, public authorities, technical review, ecological reality, and correction rather than hardening into unreviewable assumptions.**

***

### **40.10 Baseline Correction**

40.10.1 Baseline Correction is the process of revising, narrowing, reclassifying, suspending, withdrawing, replacing, or superseding a Baseline when evidence, method, authority, context, safeguards, technical review, or challenge shows that the existing Baseline is wrong, incomplete, unsafe, stale, overbroad, or no longer fit for purpose.

40.10.2 Baseline Correction is necessary because Baselines are relied upon by many downstream artifacts. A wrong Baseline can corrupt AEPs, dashboards, public-safe reports, technical findings, maturity records, routeability determinations, public authority interfaces, and project handoffs. Baseline error is systemic error.

40.10.3 A Baseline Correction should identify the affected Baseline, version, correction trigger, evidence reviewed, reviewing function, correction type, new version, affected claims, affected dockets, affected public-safe outputs, affected routeability records, affected maturity states, affected technical findings, public-safe notice requirement, and re-entry pathway.

40.10.4 Correction types may include clarification, limitation, data update, method update, threshold update, public authority capacity correction, safeguards restriction, technical correction, ecological correction, community correction, financial-readiness correction, withdrawal, supersession, or emergency hold.

40.10.5 Baseline Correction must propagate. If a Baseline supporting a proof pack changes, the proof pack must be reviewed. If a dashboard baseline changes, dashboard state may need update. If a public authority baseline changes, public claims must be corrected. If an ecological baseline changes, routeability and public-safe reporting may need re-evaluation.

40.10.6 Baseline Correction must include public-safe communication where reliance occurred. If public audiences, communities, public authorities, finance readers, providers, or downstream actors relied on the prior Baseline, they may need notice. Sensitive details may remain controlled, but corrected meaning should be communicated.

40.10.7 Baseline Correction must preserve history. The prior Baseline should not simply disappear. It should be marked corrected, superseded, withdrawn, or limited, with date and reason. Historical traceability protects accountability.

40.10.8 The doctrine is direct:

**Baseline Correction protects the Rail from systemic error by revising reference states and propagating that revision through every claim, decision, dashboard, proof pack, and handoff that relied on them.**

***

### **40.11 Baseline Drift**

40.11.1 Baseline Drift is the divergence between a recorded Baseline and the changing reality, method, system, context, authority, data, ecological condition, social condition, technical configuration, or readiness state it is supposed to represent. Drift may be gradual, sudden, visible, hidden, technical, ecological, social, legal, financial, or institutional.

40.11.2 Baseline Drift is dangerous because it creates false reliance. A sensor baseline may remain on record after devices degrade. An ecological baseline may remain after drought intensifies. A community baseline may remain after displacement. A public authority baseline may remain after a ministry reorganizes. A technical baseline may remain after dependencies become vulnerable. A readiness baseline may remain after safeguards concerns emerge.

40.11.3 Drift may arise from environmental change, system change, technology change, legal change, social change, data-quality change, model drift, sensor drift, institutional change, funding change, provider change, public authority change, community trust change, conflict, incident, or cumulative risk. Baseline governance must anticipate drift rather than treat it as exceptional.

40.11.4 Baseline Drift detection may use monitoring, periodic review, observatory signals, community feedback, TMD re-review, sensor recalibration, public authority updates, incident reports, platform alerts, AI-assisted anomaly detection, evidence-gap review, and challenge processes. Drift detection must combine machine and human intelligence.

40.11.5 Drift must be classified. Some drift is minor and requires notation. Some requires baseline update. Some requires maturity downgrade. Some requires routeability suspension. Some requires public-safe correction. Some requires emergency incident mode. The response must match consequence.

40.11.6 Drift must be visible in dashboards and records where relevant. A Baseline should not remain displayed as current if drift is suspected or under review. Status labels such as current, under review, drift detected, corrected, superseded, suspended, or withdrawn should be used.

40.11.7 Drift review must be anti-capture. Actors benefiting from an outdated Baseline may resist updates. Sponsors, providers, public authorities, project vehicles, or finance actors may prefer old assumptions. The Rail must protect the ability to revise Baselines when reality changes.

40.11.8 The doctrine is direct:

**Baseline Drift is the warning that a reference state may no longer represent reality; detecting and correcting drift is essential to prevent stale evidence from becoming false assurance.**

***

### **40.12 Baselines as Living Governance Objects**

40.12.1 Baselines are living governance objects. They are not background data, technical annexes, or one-time project inputs. They are active reference states that shape evidence, maturity, readiness, routeability, public-safe communication, technical verification, public authority interfaces, dashboards, monitoring, correction, and learning across the Rail.

40.12.2 Baselines are living because the world they describe is living. Ecologies change. Communities change. Technologies change. Public authorities change. Data systems change. Infrastructure changes. Models change. Finance conditions change. Trust changes. A governance system that treats Baselines as static will govern yesterday’s reality.

40.12.3 As living governance objects, Baselines require owners or stewards, versioning, review cycles, challenge routes, correction procedures, publication classification, dependency links, and maturity states. A Baseline without stewardship will decay. A Baseline without challenge will harden into assumption. A Baseline without correction will spread error.

40.12.4 Baselines must be integrated into AEPs, OSI dockets, Observatory Records, TMD Records, Platform Records, National Governance Records, Regional Records, GRF maturity records, GRA routeability records, and downstream handoff records. They should not sit in isolated technical repositories. Baseline validity must travel with governance reliance.

40.12.5 Baselines must support human–machine–nature governance. Humans interpret and authorize Baselines. Machines help monitor, compare, and detect drift. Nature supplies signals and constraints. Communities provide lived truth and challenge. Public authorities provide lawful context. Technical experts provide method. The Baseline becomes legitimate when these forms of intelligence remain bounded and connected.

40.12.6 Baselines must be public-safe where appropriate. Public trust often requires understanding what reference state is being used. But public-safe does not mean full disclosure of sensitive data. A Baseline may have public summary, controlled technical annex, protected knowledge restriction, and internal dependency map.

40.12.7 Baselines must support lawful action without becoming action. They make decisions better, but they do not decide. They make finance-readable evidence stronger, but they are not financial advice. They make public authority learning clearer, but they are not approval. They make technical verification possible, but they are not certification. Their power is reference, not command.

40.12.8 The final doctrine of this chapter is direct:

**Baselines are the living reference objects of Planetary Nexus Governance. They allow the Rail to know what has changed, what remains uncertain, what is ready, what has drifted, what must be corrected, and what can responsibly be relied upon—without confusing reference states with authority, approval, or execution.**


---

# 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/vii.-evidence/40.-baselines.md?ask=<question>
```

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

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