91. Legal
91.1 Legal Diversity
91.1.1 Legal Diversity is the doctrine that Planetary Nexus Governance must operate across different constitutional systems, legal traditions, regulatory structures, public authority mandates, civil liability regimes, administrative laws, procurement systems, public finance systems, professional rules, insurance frameworks, data protection laws, AI rules, Indigenous and community rights regimes, labour laws, environmental laws, and dispute systems without assuming that one legal model applies everywhere.
91.1.2 Legal Diversity requires that the Rail be portable in method but not uniform in legal effect. A proof pack, dashboard, maturity state, routeability record, assurance record, facility-grade readiness state, public-safe summary, or finance-readiness pathway may have one meaning in one jurisdiction and a different legal consequence in another. The common Rail may structure records, but national and local law determines legal effect.
91.1.3 Legal Diversity must be addressed before public claims, capital-reader access, donor reporting, procurement-preparation language, public authority interfaces, data sharing, AI processing, cross-border observability, protected knowledge handling, or implementation handoff. A pathway that is technically coherent but legally ungrounded is not governance-ready.
91.1.4 Legal Diversity includes differences in nonprofit law, charity law, company law, trust law, association law, public law, tort law, contract law, administrative procedure, environmental assessment, land law, Indigenous rights, data protection, cybersecurity duties, public procurement, public finance, securities law, insurance law, professional licensing, emergency powers, public health law, and sector-specific regulation. No Nexus template may presume away these differences.
91.1.5 Legal Diversity must not be used as a reason for inaction where safe support is possible. The Rail may begin with supported-only status, legal-basis scoping, public authority capacity records, local legal mapping, claims limits, and no-reliance language while legal conditions are clarified. Legal uncertainty should be recorded and routed, not hidden.
91.1.6 Legal Diversity must be reflected in National Law Overlays. Every country pathway, regional pathway, facility-grade process, data-zone arrangement, finance-readiness pathway, and public authority interface should identify applicable legal domains, open legal questions, competent authorities, required permissions, prohibited uses, and reliance limits.
91.1.7 Legal Diversity must be correction-linked. When laws change, courts decide, regulators clarify, public authorities issue guidance, agreements expire, national circumstances shift, or legal interpretations are corrected, dependent Nexus records, dashboards, proof packs, maturity states, public-safe summaries, and handoff records must update.
91.1.8 The doctrine is direct:
Legal Diversity means the Rail may be common, but legal effect is local. Planetary Nexus Governance must travel through law, not over it.
91.2 Liability Ambiguity
91.2.1 Liability Ambiguity is the risk that users, public authorities, communities, funders, sponsors, hosts, capital readers, vendors, implementers, operators, or Nexus bodies may misunderstand who is responsible for harm, reliance, professional judgment, data use, technical error, public claims, implementation decisions, or downstream action arising from Nexus records, dashboards, proof packs, assurance outputs, technical assistance, or handoffs.
91.2.2 Liability Ambiguity may arise because the Rail produces outputs that look authoritative: maturity states, dashboards, proof packs, readiness gates, public-safe summaries, routeability records, assurance findings, technical baselines, facility-grade records, public-value finance records, and correction notices. Without clear limits, these outputs may be mistaken for guarantees, approvals, instructions, professional opinions, warranties, investment materials, procurement decisions, or public authority actions.
91.2.3 Liability Ambiguity may also arise through role overlap. A host may also be a sponsor. A public authority may participate as learner and later as regulator. A technical expert may also work for a vendor. A donor may fund a pathway and publish claims. A capital reader may ask questions that shape proof-pack readability. Each role must be separated and recorded.
91.2.4 Liability Ambiguity records should identify the object, actor roles, reliance audience, permitted use, prohibited use, professional boundaries, public authority status, execution boundary, data boundary, AI boundary, insurance boundary, contractual boundary, known ambiguity, and correction route.
91.2.5 Liability Ambiguity must be mitigated through role language. Nexus records should state whether an output is advisory, evidentiary, public-safe, internal, controlled, finance-readable, technical, non-advisory, non-executing, non-certifying, non-regulatory, non-procurement, non-investment, or non-insurance in character. Silence invites false reliance.
91.2.6 Liability Ambiguity must be mitigated through lawful handoff records. When a pathway moves to an operator, public authority, procurement actor, project vehicle, licensed professional, insurer, lender, donor, or implementer, the handoff record must identify what is being handed off, what is not being handed off, who makes subsequent decisions, what reliance is bounded, and what correction duties remain.
91.2.7 Liability Ambiguity must be corrected where external actors misuse Nexus outputs. If a sponsor cites a proof pack as approval, a vendor cites facility-grade readiness as certification, a donor cites a dashboard as impact proof, a capital reader treats routeability as investment recommendation, or a public authority participant is misrepresented as decision-maker, the Rail must issue correction.
91.2.8 The doctrine is direct:
Liability Ambiguity is reduced by precision: every Nexus output must show who is responsible for what, who is not responsible for what, what may be relied upon, what may not be relied upon, and where lawful decision-making actually sits.
91.3 Bounded Reliance
91.3.1 Bounded Reliance is the doctrine that any permitted reliance on Nexus records, proof packs, dashboards, assurance outputs, public-safe summaries, technical baselines, maturity states, routeability records, finance-readiness materials, facility-grade records, or handoff records must be limited by purpose, audience, scope, date, source records, assumptions, publication class, legal boundary, and correction status.
91.3.2 Bounded Reliance prevents Nexus outputs from becoming universal claims. A proof pack may be relied upon by an authorized capital reader only for understanding evidence status and routeability gaps, not for investment advice. A dashboard may be relied upon for viewing current record state, not for legal approval. A public-safe summary may be relied upon for high-level understanding, not for full technical detail. A facility-grade record may be relied upon for a defined gate, not for safety certification.
91.3.3 Bounded Reliance records should identify intended users, permitted purpose, excluded users, excluded purposes, evidence scope, temporal scope, geographic scope, legal scope, technical scope, public authority scope, data scope, safeguards scope, assumptions, limitations, correction status, and expiration or review date.
91.3.4 Bounded Reliance must include negative reliance language. It should state that the record does not constitute legal advice, investment advice, insurance advice, professional engineering certification, medical advice, public authority approval, procurement decision, regulatory compliance determination, credit rating, underwriting opinion, safety guarantee, or execution instruction unless a separate lawful record provides such effect.
91.3.5 Bounded Reliance must be visible before access where consequence is material. Capital-reader rooms, donor portals, controlled dashboards, proof packs, facility-grade records, and technical assurance records should require users to understand reliance limits before using materials. Reliance limits hidden in annexes are weak.
91.3.6 Bounded Reliance must be updated when records change. If a baseline is corrected, a dashboard is superseded, a proof pack is narrowed, a public authority capacity changes, a safeguards incident occurs, or a data-zone condition changes, reliance limits and affected users must be updated.
91.3.7 Bounded Reliance must not be used to avoid responsibility for reckless record production. Reliance limits protect against misuse; they do not excuse negligent, misleading, unsafe, inaccessible, uncorrected, or overclaimed Nexus outputs. Bounded reliance must pair with assurance and correction.
91.3.8 The doctrine is direct:
Bounded Reliance lets Nexus records be useful without becoming universal guarantees. Every reliance right must be specific, limited, dated, scoped, authority-bounded, and correction-linked.
91.4 Duty of Care
91.4.1 Duty of Care is the doctrine that Nexus bodies, hosts, sponsors, experts, platform operators, data custodians, technical reviewers, safeguards actors, secretariats, and other participants must exercise reasonable and role-appropriate care when creating, handling, displaying, routing, publishing, correcting, or handing off governance records and public-good outputs. The Rail’s non-executing role does not eliminate care obligations.
91.4.2 Duty of Care must be role-specific. A Secretariat has duties of record integrity, classification, versioning, and correction. A technical reviewer has duties of method honesty and limitation disclosure. A safeguards actor has duties of protection and escalation. A platform operator has duties of access control, security, and availability. A host has duties of non-control and custody. A sponsor has duties not to misuse association. A capital reader has duties to respect reliance limits.
91.4.3 Duty of Care should be defined in instruments, role records, participation terms, data agreements, host agreements, donor agreements, platform terms, expert mandates, capital-reader room terms, and handoff records. Where duties are unclear, ambiguity should be treated as a risk to be clarified before high-consequence use.
91.4.4 Duty of Care requires foreseeable harm review. Before publication, routing, dashboard display, proof-pack access, AI processing, protected knowledge use, or facility-grade claim, the responsible function must consider reasonably foreseeable harms: misinterpretation, exposure, overclaim, reliance misuse, data breach, retaliation, public authority confusion, procurement steering, financialization, or implementation harm.
91.4.5 Duty of Care requires competence. Persons or bodies performing technical assurance, safeguards review, data governance, cyber review, public authority classification, finance-readiness assurance, or legal-boundary review must have appropriate competence or seek qualified support. Good intent is not enough for high-consequence work.
91.4.6 Duty of Care requires timely correction. Once a responsible function knows or should know that a record, dashboard, public claim, proof pack, data access, AI output, or handoff is materially wrong, unsafe, outdated, overclaimed, or misused, it must act within an appropriate correction clock.
91.4.7 Duty of Care must be documented. Care is shown through records: review logs, assurance findings, safeguards screening, legal boundary notes, publication approvals, access logs, corrections, dependency updates, and public-safe notices. Undocumented care may not be governable.
91.4.8 The doctrine is direct:
Duty of Care means that non-execution is not negligence permission. Every Nexus actor must exercise care appropriate to its role, the consequence of the output, and the foreseeable reliance it may create.
91.5 Professional Boundaries
91.5.1 Professional Boundaries are the limits that prevent Nexus outputs, experts, staff, volunteers, reviewers, advisors, AI tools, dashboards, proof packs, or technical assistance activities from being mistaken for licensed professional services, regulated advice, statutory decisions, or expert certifications that require separate authority, qualifications, licensure, insurance, or engagement terms.
91.5.2 Professional Boundaries apply to law, engineering, architecture, medicine, public health, accounting, audit, insurance, actuarial work, investment advice, credit rating, securities advice, procurement advice, environmental assessment, geotechnical work, nuclear safety, biosecurity, cybersecurity, data protection, land surveying, valuation, and other regulated or professional domains.
91.5.3 Professional Boundary records should identify professional domain implicated, Nexus role, licensed professional role if any, required qualifications, advisory limits, reliance limits, handoff need, disclaimers, review status, and correction route. Where a licensed professional is engaged, the record should distinguish their professional opinion from the Rail’s governance record.
91.5.4 A Nexus technical finding is not automatically an engineering certification. A public-health evidence pack is not medical advice. A legal-basis note is not legal advice to the public. A finance-readiness proof pack is not investment advice. A cyber assurance record is not a guarantee of security. A facility-grade readiness gate is not operational safety certification. These boundaries must be express.
91.5.5 Professional Boundaries must not block legitimate public-good explanation. The Rail may explain records, risks, assumptions, gaps, public authority boundaries, safeguards, and routeability in plain language. It may support lawful actors. The boundary is crossed when the Rail presents itself as providing professional judgment reserved to regulated actors or invites reliance beyond its role.
91.5.6 Professional Boundaries require referral or handoff. Where a matter requires legal opinion, engineering stamp, medical judgment, environmental approval, procurement advice, insurance underwriting, investment advice, or other licensed service, the Rail should route the matter to competent lawful actors rather than simulating the service.
91.5.7 Professional Boundary breaches must trigger correction. If a Nexus record or actor has been interpreted as professional advice or certification beyond scope, public-safe clarification, controlled correction, revised language, or handoff correction may be required.
91.5.8 The doctrine is direct:
Professional Boundaries ensure that Nexus governance supports expert and public decision-making without pretending to provide licensed professional services, regulated advice, certification, or statutory determinations it is not authorized to provide.
91.6 Insurance and Risk Transfer
91.6.1 Insurance and Risk Transfer is the doctrine that Nexus records may help make risk more visible, structured, and finance-readable, but they do not themselves create insurance coverage, underwriting approval, risk transfer, guarantee, indemnity, actuarial opinion, loss certification, claim payment, premium determination, or insurability conclusion unless a separate lawful insurance or risk-transfer actor makes such decision within its mandate.
91.6.2 Insurance-related ambiguity may arise where proof packs, resilience dashboards, facility-grade readiness records, disaster risk intelligence, public-value finance records, climate adaptation records, cyber assurance records, or continuity records are reviewed by insurers, reinsurers, guarantors, public risk pools, catastrophe bond actors, resilience finance actors, or public finance bodies. These actors may read records, but the Rail does not underwrite.
91.6.3 Insurance and Risk Transfer records should identify insurance or risk-transfer actor, role, materials reviewed, permitted reliance, prohibited reliance, loss data, model limitations, public authority relevance, community safeguards, data restrictions, underwriting boundary, claims boundary, and correction route.
91.6.4 Nexus outputs must avoid implying coverage or risk reduction guarantees. A resilience score, continuity dashboard, facility readiness state, cyber assurance finding, hazard baseline, or adaptation proof pack may support understanding, but it does not prove that loss will not occur or that a risk is insurable.
91.6.5 Insurance and Risk Transfer must include equity review. Risk transfer can protect communities, but it can also exclude high-risk groups, raise premiums, shift burden, privatize resilience, or create moral hazard. Public-value finance records must track who benefits, who pays, who remains uninsured, and who bears residual risk.
91.6.6 Insurance and Risk Transfer must include data safeguards. Insurance actors may seek granular risk data about communities, facilities, health, cyber vulnerabilities, or hazards. Finance interest does not create access to sensitive or protected records. Public-safe and role-keyed access must apply.
91.6.7 Insurance-related misuse must trigger correction. If an insurer, sponsor, donor, or implementer cites Nexus outputs as underwriting approval, risk guarantee, loss certification, premium validation, or resilience certification beyond the record, the claim must be corrected.
91.6.8 The doctrine is direct:
Nexus risk records may inform lawful insurance and risk-transfer actors, but they do not transfer risk. Insurance decisions remain with lawful insurers and public risk-transfer bodies, under bounded reliance and safeguards.
91.7 Public Claims Liability
91.7.1 Public Claims Liability is the risk that statements, labels, dashboards, press releases, donor reports, public-safe summaries, websites, maps, maturity states, recognition language, finance-readiness language, facility-grade language, public authority references, community references, or sponsor claims create legal, reputational, regulatory, contractual, public trust, or harm exposure because they are false, misleading, unsupported, outdated, overbroad, or unsafe.
91.7.2 Public Claims Liability is heightened where language suggests approval, certification, recognition, public authority endorsement, community consent, Indigenous support, investment readiness, procurement status, safety, resilience, compliance, maturity, verified impact, nature-positive status, public-value delivery, or risk reduction. These claims require records.
91.7.3 Public Claims Liability records should identify claim, speaker, publication channel, audience, supporting records, permitted language, prohibited language, authority basis, reliance risk, sensitivity risk, correction route, and whether public-safe review occurred.
91.7.4 Public claims must be supported by current records. A claim valid yesterday may be false today if a dashboard is corrected, a maturity state is downgraded, a public authority clarifies non-approval, a community withdraws consent, a safeguards incident occurs, or a proof pack is superseded.
91.7.5 Public claims must be scoped. “Supported by Nexus,” “Nexus-aligned,” “public-value ready,” “finance-readable,” “facility-grade,” “recognized,” “mature,” “active,” “community-informed,” “public authority engaged,” and similar terms must have controlled meanings. Broad promotional language must be avoided.
91.7.6 Public claims must include correction channels. Public-facing materials should make clear where corrections may be submitted, how status is verified, and whether records have been superseded. Claims discipline includes public accountability.
91.7.7 Public Claims Liability must be actively monitored. Sponsors, donors, hosts, vendors, capital readers, media, public authorities, and internal teams may reuse Nexus language incorrectly. Misuse must trigger claims correction, access restrictions, public-safe clarification, or legal-boundary review.
91.7.8 The doctrine is direct:
Public claims are liability-bearing governance objects. No Nexus claim may outrun its record, its authority, its sensitivity class, its reliance limits, or its correction status.
91.8 Data Liability
91.8.1 Data Liability is the legal, ethical, operational, reputational, and public-trust risk arising from collection, custody, sharing, processing, publication, retention, deletion, breach, misuse, unauthorized access, cross-border transfer, AI ingestion, re-identification, or correction failure involving data used within Planetary Nexus Governance.
91.8.2 Data Liability may involve personal data, health data, worker data, community-sensitive data, protected knowledge, public authority-sensitive records, cyber-sensitive records, finance-sensitive annexes, geospatial data, sensor data, grievance records, model inputs, AI prompts, logs, metadata, and dashboard outputs. Metadata itself may create liability where it reveals identity, location, or protected relationships.
91.8.3 Data Liability records should identify data class, custodian, controller or equivalent role where applicable, processor or equivalent role where applicable, lawful basis, consent or permission, purpose, access roles, cross-border transfers, AI permissions, retention, deletion, publication class, breach procedure, correction rights, and incident history.
91.8.4 Data Liability must be addressed through data minimization. The Rail should collect only what is necessary for a defined governance purpose, at the lowest safe granularity, with the least exposure, and with clear retention and correction rules. Data hoarding is liability creation.
91.8.5 Data Liability must include re-identification and inference risk. Aggregated or anonymized data may still reveal people, communities, protected places, vulnerabilities, or sensitive facilities when combined with other records. Public-safe release must account for inference.
91.8.6 Data Liability must include AI processing risk. Data entered into AI systems may be logged, embedded, retained, reproduced, inferred from, or reused. Protected data must not be processed by AI unless permitted by data class, lawful basis, technical controls, and human review.
91.8.7 Data incidents must trigger correction and notification review. Unauthorized access, breach, improper disclosure, public-safe release error, AI ingestion, cross-border transfer violation, or deletion failure may require containment, public authority notification where required, affected-person or custodian notice, dashboard correction, proof-pack supersession, and access restriction.
91.8.8 The doctrine is direct:
Data Liability is governed by custody, purpose, minimization, sensitivity, lawful basis, access control, AI restriction, public-safe release, incident response, and correction. The Rail must never treat data as harmless because its purpose is public good.
91.9 AI and Model Liability
91.9.1 AI and Model Liability is the risk that AI systems, models, digital twins, classifiers, scoring systems, geospatial models, hazard models, finance-readiness tools, dashboards, agentic workflows, simulations, or automated summaries produce error, bias, overclaim, unauthorized advice, protected knowledge exposure, public authority confusion, discriminatory impact, unsafe reliance, or downstream harm.
91.9.2 AI and Model Liability is heightened because model outputs can appear objective, authoritative, scalable, and current even when they are uncertain, biased, incomplete, outdated, hallucinated, poorly validated, or outside scope. A model can produce governance harm at machine speed.
91.9.3 AI and Model Liability records should identify model or AI system, version, owner or operator, purpose, data sources, training or inference context, permitted use, prohibited use, human review, validation status, bias review, protected knowledge restrictions, public authority boundary, professional boundary, output class, reliance limits, incident history, and correction route.
91.9.4 AI and model outputs must not be final authority. They may support evidence review, anomaly detection, scenario exploration, drafting, translation, or routing, but they must not finally determine maturity, routeability, public authority capacity, safeguards clearance, community consent, legal compliance, investment readiness, procurement status, public warning, or facility safety.
91.9.5 AI and Model Liability requires human accountability. Every material machine-assisted output must have an accountable human or governance function responsible for review, adoption, limitation, publication, correction, or withdrawal. “The model said” is not a liability boundary.
91.9.6 AI and Model Liability requires explainability proportionate to consequence. Users and affected people must be able to understand what the model was used for, what data informed it, what assumptions apply, what uncertainty exists, what it does not decide, and how to challenge it. Black-box outputs should not carry high-governance consequence without special controls.
91.9.7 AI and model incidents must trigger correction. Hallucinated public-safe summaries, biased classification, false geospatial inference, protected knowledge exposure, wrong translation, erroneous risk score, or unauthorized advice-like output may require takedown, reclassification, human review, model restriction, user notice, and dependent-record correction.
91.9.8 The doctrine is direct:
AI and Model Liability is controlled by purpose limits, human accountability, validation, bias review, protected knowledge controls, no-authority rules, explainability, incident response, and correction. Machines may inform governance, but they may not absorb liability into opacity.
91.10 Legal Risk Records
91.10.1 Legal Risk Records are the official records through which legal diversity, liability ambiguity, bounded reliance, duty of care, professional boundaries, insurance and risk transfer limits, public claims liability, data liability, AI and model liability, reliance boundaries, and lawful handoff conditions become visible, reviewable, controlled, and correctionable within Planetary Nexus Governance.
91.10.2 Legal Risk Records may include legal-basis records, national law overlay records, liability screening records, reliance statements, duty-of-care records, professional boundary records, insurance boundary records, public claims review records, data liability records, AI liability records, public authority boundary records, handoff records, legal incident records, and correction trails.
91.10.3 Legal Risk Records should identify object, jurisdiction, applicable legal domains, legal basis, actors, roles, reliance audience, professional domains, public authority relevance, data classes, AI use, insurance relevance, public claims, known uncertainties, mitigation controls, review date, and correction route.
91.10.4 Legal Risk Records must distinguish legal review from legal advice. Internal or governance legal-boundary records may help the Rail avoid overclaim and route matters properly, but they do not necessarily provide legal advice to public users, communities, capital readers, sponsors, or downstream actors. Reliance must be scoped.
91.10.5 Legal Risk Records must include uncertainty. Where law is unclear, contested, changing, jurisdiction-dependent, or outside the reviewing function’s competence, the record must state uncertainty and identify the need for qualified legal review, public authority clarification, or narrowed scope.
91.10.6 Legal Risk Records must be protected. Legal-sensitive materials, privileged communications, regulatory matters, disputes, claims, investigations, contractual risks, and public authority-sensitive legal issues may require restricted handling. Public-safe legal summaries may be appropriate where public claims are affected.
91.10.7 Legal Risk Records must be dependency-linked. Legal risk may affect dashboards, proof packs, public-safe summaries, maturity states, routeability, capital-reader access, donor reporting, facility-grade readiness, procurement-preparation records, and public authority interfaces. Legal corrections must propagate.
91.10.8 The doctrine is direct:
Legal Risk Records make legal boundaries governable by recording legal basis, reliance limits, liability risks, professional boundaries, data and AI risks, public claims limits, uncertainty, and correction.
91.11 Reliance Boundaries in Proof Packs and Dashboards
91.11.1 Reliance Boundaries in Proof Packs and Dashboards are the specific rules that prevent high-visibility governance objects from being misunderstood as approvals, guarantees, recommendations, ratings, certifications, public authority decisions, procurement decisions, investment materials, insurance opinions, or execution instructions.
91.11.2 Proof Packs must contain reliance statements at the front, not only in annexes. They should state the intended users, permitted purpose, excluded purposes, evidence scope, public authority status, safeguards status, routeability gaps, finance-readiness limits, professional boundaries, data restrictions, correction status, and review date.
91.11.3 Dashboards must display reliance boundaries near the visible state. A colour, score, maturity label, routeability icon, or readiness badge should be accompanied by source date, scope, authority limit, and correction status. Dashboard reliance limits must be designed into the interface.
91.11.4 Proof Packs must not be formatted as investment memoranda unless a separate lawful actor prepares transaction materials outside the Rail. They may include public-value thesis, evidence lineage, routeability gaps, safeguards, public authority capacity, monitoring conditions, and bounded capital-reader notes, but must not recommend investment, returns, underwriting, lending, procurement, or insurance.
91.11.5 Dashboards must not imply public decision by design. Labels such as “approved,” “cleared,” “safe,” “investment ready,” “procurement ready,” “compliant,” or “certified” should not be used unless the relevant lawful authority record exists. Safer state language should state “recorded,” “under review,” “valid for defined use,” “controlled-use ready,” “public-safe summary issued,” “routeability gaps active,” or similar bounded terms.
91.11.6 Proof Packs and Dashboards must be correction-forward. Users must know whether the object is current, corrected, superseded, under review, paused, narrowed, or withdrawn. Where prior reliance may exist, correction notices must be visible or notified to authorized users.
91.11.7 Reliance Boundary misuse must trigger access and claims controls. If a proof pack or dashboard is used externally to claim approval, investment merit, procurement status, community consent, public authority endorsement, or risk guarantee, the Rail may restrict access, revise labels, issue correction, notify readers, or downgrade status.
91.11.8 The doctrine is direct:
Proof Packs and Dashboards are reliance-sensitive objects. They must show exactly what they support and what they do not support, because their visibility can create reliance faster than users read the underlying record.
91.12 Lawful Handoff Without Execution
91.12.1 Lawful Handoff Without Execution is the final doctrine of this chapter. It governs how Nexus records, proof packs, dashboards, technical assistance outputs, facility-grade records, assurance findings, public-value finance records, public authority capacity records, safeguards conditions, monitoring duties, and correction trails may be transferred to lawful downstream actors without the Rail becoming the executor, procurer, regulator, financier, operator, insurer, professional adviser, or guarantor of downstream action.
91.12.2 A lawful handoff may be made to a public authority, licensed professional, procurement body, public finance body, donor, operator, National Consortium Company, Project SPV, utility, host institution, community node, insurer, lender, capital reader, technical implementer, or other competent actor. The handoff must state the actor’s role and the limits of what is transferred.
91.12.3 Handoff records should identify handing body, receiving actor, receiving capacity, object handed off, source records, permitted use, prohibited use, reliance limits, public authority status, professional boundary, safeguards conditions, data restrictions, protected knowledge restrictions, monitoring expectations, correction duties, expiration or review date, and feedback route.
91.12.4 Handoff must not imply endorsement of downstream action. The fact that a proof pack is handed to a capital reader, a facility record to an operator, a technical baseline to a public authority, or a priority register to a procurement body does not mean the Rail approves what happens next. Lawful actors must make their own decisions under their mandates.
91.12.5 Handoff must preserve safeguards-to-covenant logic. Where material safeguards, public-value conditions, data restrictions, protected knowledge controls, affordability commitments, monitoring duties, or grievance routes must travel downstream, the handoff record should identify them clearly for lawful actors to address in their own instruments.
91.12.6 Handoff must preserve correction routes. If source records are corrected after handoff, the receiving actor should be notified where reliance exists and where lawful and practicable. If downstream actors identify errors, implementation gaps, legal issues, or harm, they should have a route to return correction to the Rail.
91.12.7 Handoff must include execution firewall language. The Rail may support evidence, readiness, assurance, routeability, and public-safe reporting, but the receiving actor is responsible for lawful execution, professional judgment, regulatory compliance, procurement, financing, operation, insurance, construction, service delivery, or implementation decisions within its mandate.
91.12.8 The final doctrine is direct:
Legal, Liability, and Reliance Limits make the Rail usable without making it omnipotent. Planetary Nexus Governance can support lawful action only when legal basis, duty of care, professional boundaries, data and AI liability, bounded reliance, public claims discipline, and handoff limits are explicit, recorded, and correctable.
Last updated
Was this helpful?