Digital Twin and Critical Systems Layer

The Digital Twin and Critical Systems Layer is the Nexus architecture for creating, governing, testing, publishing, correcting, and continuing digital twins, exposure maps, system models, infrastructure models, corridor models, basin models, climate adaptation models, finance-readiness exposure maps, insurance protection gap maps, and decision-support artifacts used in national, regional, and global risk readiness pathways. It allows Nexus to represent complex systems for bounded learning and readiness while preserving the core rule: a digital twin is not the system, the authority, or the decision.

Definition

The Digital Twin and Critical Systems Layer governs the use of digital representations of real or conceptual systems within Nexus.

Digital twins may represent systems, assets, dependencies, hazards, exposure, infrastructure, corridors, basins, climate adaptation pathways, public finance exposure, finance-readiness questions, insurance protection gaps, and scenario conditions.

This layer supports National Nexus Consortiums, Regional Nexus Consortiums, Nexus Core, Nexus Network, Nexus Universe, Nexus Registry, Nexus Reports, Nexus Rails, scenario and stress-testing records, technical-readiness records, verification records, finance-readiness records, insurance-readiness questions, public authority learning records, community safeguard records, data safeguard records, and lawful handoff records.

The governing rule is:

A digital twin is a governed representation of a system for bounded learning and readiness. It is not the system, the authority, or the decision.

Why Digital Twins Matter

Systemic risk is difficult to understand when dependencies are invisible.

Water systems depend on energy. Energy systems depend on water, cyber systems, critical minerals, finance, and infrastructure. Food corridors depend on ports, fuel, cold chains, water, labor, logistics, and public health. Health systems depend on supply chains, workforce capacity, digital systems, energy, water, sanitation, and public trust. Cities depend on transport, housing, drainage, public services, finance, data, and infrastructure. Critical infrastructure depends on physical, digital, social, financial, and institutional systems at the same time.

Digital twins help make these relationships visible.

They can support learning, stress testing, exposure mapping, scenario analysis, public-safe visualization, technical verification, finance-readiness readability, insurance-readiness questioning, public authority learning, and lawful handoff.

But a digital twin can also be dangerous if it is overstated.

A model can be mistaken for reality. A dashboard can be mistaken for official statistics. An exposure map can be mistaken for public authority approval. A finance-readiness map can be mistaken for financeability. An insurance protection gap map can be mistaken for underwriting. A city twin can be mistaken for municipal authority. A critical infrastructure twin can expose sensitive vulnerabilities. A biodiversity map can reveal sensitive species locations or Indigenous knowledge.

This layer exists to prevent those errors.

What the Digital Twin and Critical Systems Layer Is

The Digital Twin and Critical Systems Layer is a governed decision-support architecture.

It may support:

• national systems digital twins;
• regional corridor twins;
• water basin twins;
• energy grid twins;
• food corridor twins;
• health-system capacity twins;
• city resilience twins;
• port and logistics twins;
• critical infrastructure twins;
• biodiversity and land-use twins;
• climate adaptation twins;
• public finance exposure maps;
• finance-readiness exposure maps;
• insurance protection gap maps;
• digital twin data governance;
• digital twin model governance;
• digital twin verification records;
• digital twin publication boundaries;
• Nexus Rails continuation.

Digital twin records should be data-governed, model-governed, evidence-bounded, assumption-labeled, uncertainty-labeled, security-aware, privacy-aware, public-safe, decision-use-labeled, correction-ready, and lawfully continuable.

What the Digital Twin and Critical Systems Layer Is Not

The Digital Twin and Critical Systems Layer is not a decision authority.

Digital twins should not be treated as reality, official system models, public authority determinations, engineering approvals, regulatory approvals, procurement approvals, investment advice, underwriting conclusions, financeability determinations, insurability determinations, certification, social license, consent, professional assurance, project approval, operational authorization, or implementation authority.

A digital twin may support a competent actor’s learning or decision process. It does not replace that actor’s lawful authority, professional judgment, public mandate, community process, Indigenous consent process, engineering responsibility, underwriting responsibility, investment responsibility, procurement process, or implementation accountability.

The rule is:

Digital twins support decisions made by competent actors. They do not make the decisions.

National Systems Digital Twins

National Systems Digital Twins may represent national systems, dependencies, exposure, resilience gaps, public service continuity, infrastructure networks, public finance exposure, technical-readiness questions, and lawful handoff conditions.

They may support National Nexus Consortium portfolio records, National Program Office records, Nexus Core preparation, Nexus Network node readiness, public-safe reports, finance-readiness notes, public authority learning, and Nexus Rails continuation.

A National Systems Digital Twin Record should identify the system represented, national pathway, data sources, data governance conditions, model structure, assumptions, uncertainty, public authority boundaries, security sensitivity, public-safe publication limits, verification status, correction pathway, and continuation status.

A National Systems Digital Twin does not imply government approval, national mandate, official system model, national statistics, procurement approval, financeability, insurability, public authority status, project approval, or implementation authority unless separately and lawfully established.

The rule is:

A national systems twin may support national readiness records. It does not become the nation’s official model or authority.

Regional Corridor Twins

Regional Corridor Twins may represent cross-border corridors, including transport corridors, energy corridors, food corridors, water basins, trade corridors, health corridors, digital infrastructure corridors, migration corridors, maritime corridors, logistics corridors, and critical minerals corridors.

Regional Corridor Twins preserve national records first and regional federation second.

A Regional Corridor Twin Record should identify the corridor represented, countries or systems involved where appropriate, national source records, cross-border dependencies, data sovereignty controls, conflict-sensitive context where applicable, public authority boundaries, regional organization boundaries, competition safeguards, public-safe publication limits, verification status, correction pathway, and continuation status.

Regional Corridor Twins do not imply treaty interpretation, diplomatic authority, regional authority, official boundary recognition, sanctions advice, trade policy decision, procurement approval, financeability, insurability, or implementation authority.

The rule is:

A regional corridor twin connects cross-border records without creating regional or diplomatic authority.

Water Basin Twins

Water Basin Twins may represent surface water, groundwater, watersheds, basins, floodplains, water quality, water infrastructure, drought stress, flood exposure, upstream-downstream dependencies, energy linkages, food-system linkages, health implications, biodiversity conditions, and regional water dependencies.

A Water Basin Twin Record should identify the basin or watershed represented, data sources, hydrological and ecological assumptions, data limitations, community and Indigenous knowledge safeguards, public authority boundaries, water rights boundaries, cross-border sensitivities where applicable, public-safe publication limits, verification status, correction pathway, and continuation status.

Water Basin Twins do not decide water rights, allocation, basin governance, utility operations, environmental permits, public health orders, financeability, insurability, consent, or implementation.

The rule is:

A water basin twin makes basin dependency visible without governing the basin.

Energy Grid Twins

Energy Grid Twins may represent electricity generation, transmission, distribution, storage, demand, grid stress, fuel dependencies, water dependencies, critical infrastructure links, cyber exposure, public service dependency, energy transition pathways, and resilience gaps.

An Energy Grid Twin Record should identify the grid or energy system represented, data sources, model assumptions, data sensitivity, security sensitivity, utility and operator boundaries, public authority boundaries, cyber safeguards, public-safe publication limits, verification status, correction pathway, and continuation status.

Energy Grid Twins do not approve energy policy, tariff decisions, utility operations, grid interventions, technology selection, procurement, financeability, insurability, or implementation.

The rule is:

An energy grid twin supports resilience learning without directing grid operations or energy policy.

Food Corridor Twins

Food Corridor Twins may represent food production, processing, storage, cold chains, logistics, transport corridors, trade dependencies, water inputs, energy inputs, labor dependencies, health implications, market sensitivity, and supply-continuity risks.

A Food Corridor Twin Record should identify the food corridor or system represented, data sources, dependencies, model assumptions, market-conduct sensitivity, trade-policy boundary, humanitarian sensitivity where applicable, public authority boundaries, public-safe publication limits, verification status, correction pathway, and continuation status.

Food Corridor Twins do not allocate food, direct trade, coordinate prices, approve suppliers, approve procurement, issue food security determinations, finance food systems, underwrite risks, or authorize implementation.

The rule is:

A food corridor twin maps supply continuity without coordinating food markets.

Health-System Capacity Twins

Health-System Capacity Twins may represent health-system capacity, service continuity, health infrastructure, supply chains, workforce dependencies, surge conditions, water and sanitation dependencies, digital health systems, public health signals, climate-health links, and biological risk readiness.

A Health-System Capacity Twin Record should identify the health system represented, data sources, health data sensitivity, privacy controls, public health authority boundaries, clinical guidance boundaries, biological or dual-use sensitivity where applicable, assumptions, public-safe publication limits, verification status, correction pathway, and continuation status.

Health-System Capacity Twins do not provide medical advice, clinical guidance, public health orders, official disease determinations, hospital command, health procurement approval, financeability, insurability, or implementation authorization.

The rule is:

A health-system twin supports readiness only where privacy, public health authority, and biosecurity boundaries are protected.

City Resilience Twins

City Resilience Twins may represent urban systems, heat exposure, flood exposure, housing vulnerability, transport, water, sanitation, energy, public health, social vulnerability, digital infrastructure, public safety dependencies, public finance exposure, and service continuity.

A City Resilience Twin Record should identify the city or urban system represented, data sources, municipal authority boundaries, land-use boundaries, privacy and community safeguards, infrastructure dependencies, model assumptions, public-safe publication limits, verification status, correction pathway, and continuation status.

City Resilience Twins do not approve urban plans, zoning, permits, public budgets, procurement, infrastructure interventions, financeability, insurability, consent, or implementation.

The rule is:

A city resilience twin helps read urban systems without becoming city authority.

Port and Logistics Twins

Port and Logistics Twins may represent ports, maritime corridors, transport links, shipping dependencies, storage systems, fuel supply, cyber exposure, cold chains, customs dependencies, trade corridors, emergency supply routes, and supply-chain resilience.

A Port and Logistics Twin Record should identify the port, corridor, or logistics system represented, data sources, operator boundaries, maritime or transport authority boundaries, trade-policy boundaries, market-conduct sensitivity, security sensitivity, model assumptions, public-safe publication limits, verification status, correction pathway, and continuation status.

Port and Logistics Twins do not direct port operations, regulate shipping, approve customs decisions, coordinate markets, approve suppliers, approve procurement, finance infrastructure, underwrite risks, or authorize implementation.

The rule is:

A port and logistics twin maps dependency without commanding logistics systems.

Critical Infrastructure Twins

Critical Infrastructure Twins may represent essential services, infrastructure dependencies, operational stress, cyber exposure, disaster exposure, public service continuity, infrastructure interdependency, and cascading failure pathways.

A Critical Infrastructure Twin Record should identify the infrastructure function represented, data sources, infrastructure owner or operator boundaries where known, public authority boundaries, security sensitivity, cyber sensitivity, model assumptions, public-safe publication limits, verification status, correction pathway, and continuation status.

Critical Infrastructure Twins do not disclose sensitive vulnerabilities, certify infrastructure, approve operations, direct operators, approve procurement, approve finance, underwrite risks, or authorize interventions.

Critical Infrastructure Twins should be restricted where public release could expose vulnerabilities, sensitive locations, security controls, or operational weaknesses.

The rule is:

A critical infrastructure twin must protect the infrastructure it helps make visible.

Biodiversity and Land-Use Twins

Biodiversity and Land-Use Twins may represent ecosystems, habitats, land cover, land use, species sensitivity, watershed function, food-system dependencies, climate adaptation functions, disease regulation, disaster risk reduction, cultural landscapes, and community or Indigenous knowledge safeguards.

A Biodiversity and Land-Use Twin Record should identify the ecosystem, land-use, or biodiversity system represented, data sources, sensitive location controls, community and Indigenous knowledge safeguards, environmental authority boundaries, land-use authority boundaries, model assumptions, public-safe publication limits, verification status, correction pathway, and continuation status.

Biodiversity and Land-Use Twins do not approve land use, environmental permits, conservation decisions, offset claims, nature-finance validation, community consent, Indigenous consent, financeability, insurability, or implementation.

The rule is:

A biodiversity and land-use twin must protect ecosystems and knowledge while making dependency visible.

Climate Adaptation Twins

Climate Adaptation Twins may represent climate hazards, exposure, adaptation options, infrastructure stress, public finance exposure, community vulnerability, water stress, heat, flooding, coastal risk, wildfire, drought, health impacts, food-system implications, and resilience measures.

A Climate Adaptation Twin Record should identify the climate risk or adaptation context, data sources, climate assumptions or scenarios, uncertainty, public authority boundaries, community safeguards, data sensitivity, finance-readiness relevance, insurance-readiness questions, public-safe publication limits, verification status, and continuation status.

Climate Adaptation Twins do not approve adaptation policy, environmental permits, infrastructure projects, public finance, climate finance, carbon-market claims, financeability, insurability, consent, or implementation.

The rule is:

A climate adaptation twin supports adaptation learning without approving adaptation decisions.

Public Finance Exposure Maps

Public Finance Exposure Maps may represent fiscal exposure, contingent liabilities, disaster recovery cost exposure, adaptation cost exposure, public asset exposure, health-system cost pressure, food-security cost pressure, infrastructure cost pressure, social protection exposure, tax and revenue exposure, and development-finance readiness questions.

A Public Finance Exposure Map Record should identify the exposure mapped, data sources, assumptions, uncertainty, public authority boundary, public finance boundary, fiscal advice boundary, data limitations, public-safe publication limits, correction pathway, and continuation status.

Public Finance Exposure Maps do not provide fiscal advice, budget advice, debt advice, tax advice, sovereign borrowing advice, monetary advice, public finance approval, appropriation decisions, procurement approval, financeability, or implementation authorization.

The rule is:

Public finance exposure maps make fiscal risk visible. They do not decide public finance.

Finance-Readiness Exposure Maps

Finance-Readiness Exposure Maps may represent exposure, resilience gaps, programmatic readiness, infrastructure dependency, climate adaptation need, disaster risk, public finance relevance, development-finance readiness, capital-readability questions, and diligence gaps.

A Finance-Readiness Exposure Map Record should identify the exposure or readiness theme, source records, evidence status, data quality, public authority boundary, procurement boundary, no-advice status, no-offer status, no-financeability status, no-false-capital-signal controls, public-safe publication limits, and correction pathway.

Finance-Readiness Exposure Maps do not imply investment advice, financial promotion, securities offering, lending approval, capital allocation, guarantee, rating, bankability, financeability, public finance approval, procurement approval, or market execution.

The rule is:

Finance-readiness maps make exposure readable to finance-facing actors without making it financeable.

Insurance Protection Gap Maps

Insurance Protection Gap Maps may represent exposure, vulnerability, protection gaps, data gaps, resilience measures, public asset risk, household vulnerability, agricultural exposure, infrastructure exposure, climate risk, disaster risk, and insurance-relevance questions.

An Insurance Protection Gap Map Record should identify the exposure category, protection-gap signal, data sources, data gaps, assumptions, market-conduct boundary, no-underwriting boundary, no-pricing boundary, no-coverage boundary, public-safe publication limit, correction pathway, and continuation status.

Insurance Protection Gap Maps do not imply underwriting, pricing, coverage, claims determination, insurance placement, brokerage, reinsurance placement, risk acceptance, insurance advice, insurability, or insurance product approval.

The rule is:

Insurance protection gap maps make exposure questions visible. They do not underwrite the risk.

Digital Twin Data Governance

Digital Twin Data Governance governs the intake, classification, sensitivity, metadata, provenance, lineage, access, sovereign data zones, secure data rooms, compute-to-data workflows, privacy safeguards, confidentiality controls, retention, deletion, portability, audit trails, correction history, and public-safe publishing of data used in digital twins.

A Digital Twin Data Governance Record should identify the data source, lawful access basis, data steward, data classification, sensitivity level, provenance, lineage, access controls, retention and deletion requirements, public-safe publication limits, correction pathway, and continuation status.

Data used in a digital twin should not be treated as owned by Nexus merely because it is visible, processed, modeled, mapped, or summarized within the twin.

Data visibility in a digital twin does not mean permission to disclose the underlying data, derived data, sensitive locations, community data, Indigenous knowledge, personal data, proprietary data, security-sensitive data, or public authority data.

The rule is:

Digital twin data remains governed data before, during, and after modeling.

Digital Twin Model Governance

Digital Twin Model Governance governs model structure, assumptions, parameters, methods, uncertainty, calibration, validation where possible, model-risk review, bias and limitation notes, security review, version control, execution logs, output controls, correction, and continuation.

A Digital Twin Model Governance Record should identify the model purpose, model structure, data inputs, assumptions, parameters, limitations, uncertainty, validation status, model-risk review, version, execution logs, output controls, correction pathway, and Nexus Rails continuation.

Digital twin models should not be treated as official system models, certified models, regulatory models, engineering approvals, investment models, underwriting models, procurement-ready models, or implementation-ready models unless separately and lawfully authorized.

The rule is:

The model that powers a digital twin must be governed before the twin can be trusted as decision support.

Digital Twin Verification Records

Digital Twin Verification Records document the bounded verification of a digital twin, including its data, model, assumptions, outputs, limitations, public-safe labels, decision-use labels, security conditions, and correction pathway.

A Digital Twin Verification Record should identify the twin reviewed, verification scope, evidence reviewed, data-quality controls, model-risk review, assumptions, limitations, reproducibility status where possible, public-safe label, decision-use label, verification receipt status, correction pathway, and continuation status.

Verification of a digital twin does not imply certification, official model approval, regulatory approval, engineering approval, procurement readiness, financeability, insurability, operational authorization, or implementation authority.

Where twin data, assumptions, methods, model structure, security status, or public-safe use changes, verification records should be corrected, downgraded, withdrawn, superseded, archived, or re-entered.

The rule is:

Digital twin verification verifies the record within scope. It does not certify the twin or the system represented.

Digital Twin Publication Boundaries

Digital Twin Publication Boundaries govern what digital twin outputs, maps, dashboards, images, models, scenario summaries, exposure layers, and public-safe reports may be published, restricted, redacted, delayed, withdrawn, superseded, archived, or re-entered.

Publication review should address evidence status, data sensitivity, privacy, confidentiality, cybersecurity, security sensitivity, dual-use risk, public authority boundaries, community and Indigenous knowledge safeguards, finance and insurance boundaries, sponsor and provider boundaries, competition safety, public-safe language, and correction history.

Digital twin outputs should not be published where release would disclose sensitive data, expose critical infrastructure, reveal vulnerable communities, disclose sensitive species locations, create security risk, create procurement advantage, imply approval, misstate finance-readiness, imply insurability, convert participation into consent, or weaken public trust.

Public digital twin outputs should carry decision-use labels, public-safe labels, uncertainty notes, limitation notes, source-record references where appropriate, and correction pathways.

The rule is:

Publish digital twin outputs only when the representation can be made public-safe without becoming harmful, misleading, or falsely authoritative.

Digital Twins Are Decision-Support Artifacts

Digital twins are decision-support artifacts.

A digital twin may support readiness learning, exposure mapping, stress testing, systems-risk mapping, public-safe visualization, finance-readiness readability, insurance-readiness questioning, public authority learning, technical verification, scenario development, and lawful handoff.

A digital twin should be interpreted through its source records, data governance, model governance, assumptions, uncertainty, limitations, verification status, decision-use label, public-safe label, correction history, and Nexus Rails continuation status.

A digital twin should not be used as a substitute for lawful public authority decision-making, professional engineering judgment, clinical judgment, public finance decision-making, investment decision-making, underwriting decision-making, procurement decision-making, community consent, Indigenous consent, or implementation authority.

The rule is:

Digital twins support decisions made by competent actors. They do not make the decisions.

Digital Twins Are Not Reality or Approval

Digital twins are not reality and should not be represented as reality.

They are bounded models of systems, assets, dependencies, hazards, exposure, or scenarios based on selected data, assumptions, methods, and limitations.

A digital twin should not be used to claim official truth, public authority approval, regulatory approval, engineering approval, procurement approval, investment approval, underwriting approval, financeability, insurability, social license, community consent, Indigenous consent, operational authorization, or implementation authority.

Where a digital twin is misused as reality, approval, certification, or authority, the related claim, output, publication, dashboard, report, or handoff record should be corrected, restricted, withdrawn, superseded, archived, or re-entered.

The rule is:

A digital twin is a model of a system, not the system, not the authority, and not approval.

What the Digital Twin and Critical Systems Layer Protects

The Digital Twin and Critical Systems Layer protects Nexus from model overclaim, unsafe visualization, false authority, data misuse, infrastructure exposure, finance-readiness overclaim, insurance-readiness overclaim, public authority confusion, procurement distortion, and misuse of digital representations as reality.

It prevents:

• national systems twins from becoming official national models;
• regional corridor twins from becoming diplomatic or regional authority;
• water basin twins from becoming basin governance;
• energy grid twins from directing utilities or energy policy;
• food corridor twins from coordinating food markets;
• health-system twins from becoming public health or clinical authority;
• city resilience twins from becoming municipal authority;
• port and logistics twins from commanding logistics systems;
• critical infrastructure twins from exposing vulnerabilities;
• biodiversity and land-use twins from exposing sensitive ecosystems or knowledge;
• climate adaptation twins from approving adaptation decisions;
• public finance exposure maps from becoming fiscal advice;
• finance-readiness maps from becoming financeability signals;
• insurance protection gap maps from becoming underwriting;
• digital twin data visibility from becoming disclosure permission;
• model outputs from becoming official truth;
• verification from becoming certification; and
• publication from making sensitive representations harmful or falsely authoritative.

It also protects legitimate systems learning. It allows Nexus to make dependencies visible, test assumptions, support public-safe reporting, improve finance-readiness and insurance-readiness questions, strengthen public authority learning, and continue records through Nexus Rails without claiming decision authority.

Frequently Asked Questions

What is the Digital Twin and Critical Systems Layer?

It is the Nexus architecture for creating, governing, testing, publishing, correcting, and continuing digital twins, exposure maps, system models, infrastructure models, corridor models, basin models, climate adaptation models, finance-readiness maps, insurance protection gap maps, and other decision-support artifacts.

What is a digital twin in Nexus?

A digital twin is a governed representation of a system for bounded learning and readiness. It may represent assets, dependencies, hazards, exposure, infrastructure, scenarios, corridors, basins, or systems. It is not the system, the authority, or the decision.

Are digital twins official system models?

No. A digital twin should not be treated as an official system model, public authority determination, engineering approval, regulatory approval, procurement approval, investment advice, underwriting conclusion, financeability determination, insurability determination, certification, social license, consent, project approval, operational authorization, or implementation authority.

Can digital twins support finance-readiness?

Yes. Finance-readiness exposure maps may make exposure, resilience gaps, programmatic readiness, infrastructure dependency, development-finance readiness, capital-readability questions, and diligence gaps more readable. They do not provide investment advice, financial promotion, lending approval, guarantees, ratings, bankability, financeability, public finance approval, procurement approval, or market execution.

Can digital twins support insurance-readiness?

Yes. Insurance protection gap maps may make exposure, vulnerability, data gaps, resilience measures, public asset risk, household vulnerability, agricultural exposure, infrastructure exposure, climate risk, disaster risk, and insurance-relevance questions more visible. They do not underwrite, price, place, approve coverage, determine claims, or provide insurance advice.

Can digital twin outputs be published?

Only when publication review confirms that the output can be made public-safe. Digital twin outputs should not be published where release would disclose sensitive data, expose critical infrastructure, reveal vulnerable communities, disclose sensitive species locations, create security risk, create procurement advantage, imply approval, misstate finance-readiness, imply insurability, convert participation into consent, or weaken public trust.

What records should a digital twin include?

A digital twin should include source records, data governance conditions, model governance records, assumptions, uncertainty, limitations, verification status, public-safe labels, decision-use labels, correction pathways, and Nexus Rails continuation status.

Does digital twin verification certify the twin?

No. Digital twin verification verifies the record within scope. It does not certify the twin, certify the system represented, approve the model, authorize procurement, determine financeability or insurability, or authorize implementation.

Why are publication boundaries important?

Digital twins can reveal sensitive systems, communities, locations, vulnerabilities, or knowledge. Publication boundaries ensure digital twin outputs remain public-safe, bounded, lawful, and correction-ready.

What is the core boundary?

The core boundary is that a digital twin is a governed representation of a system for bounded learning and readiness. It is not the system, the authority, or the decision.

Key Takeaway

The Digital Twin and Critical Systems Layer gives Nexus a disciplined way to represent complex systems without confusing representation with reality or decision authority.

It supports national systems twins, regional corridor twins, water basin twins, energy grid twins, food corridor twins, health-system twins, city resilience twins, port and logistics twins, critical infrastructure twins, biodiversity and land-use twins, climate adaptation twins, public finance exposure maps, finance-readiness exposure maps, insurance protection gap maps, data governance, model governance, verification, publication boundaries, and Nexus Rails continuation.

Its core discipline is simple: a digital twin is a governed decision-support artifact. It is not reality, authority, approval, finance, underwriting, consent, procurement, or implementation.