> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/ii.-architecture/compute-layer.md). # Compute Layer Building the Trust Fabric for Rule Execution, Clause Enforcement, and Global Verification ## NSF Compute Layer: Verifiable Execution Infrastructure for Sovereign, Multi-Agent, Multi-Jurisdictional Governance ### The Execution Problem in Policy Systems Traditional policy systems were built for a world in which human institutions interpreted rules, implemented them through administrative procedures, and reviewed compliance after the fact. This model depends on interpretation, institutional discretion, paper records, periodic audits, supervisory judgment, and post-event accountability. It can function where systems are slow, bounded, localized, and primarily human-operated. It becomes structurally fragile when policies must govern artificial intelligence, autonomous systems, digital twins, cyber-physical infrastructure, high-performance compute, cross-border data flows, distributed credentials, financial-readiness evidence, public-safe reporting, and machine-speed risk environments. In legacy policy systems, enforcement is often interpretive. A rule may be written in a statute, standard, treaty, procurement document, or institutional policy, but its operational meaning depends on human actors who interpret it locally. Interpretation is necessary in law and governance, but when interpretation becomes the only execution pathway, outcomes become inconsistent across agencies, jurisdictions, platforms, vendors, and operators. The same standard can produce different results depending on who reads it, which system implements it, which data is available, and which institutional pressures exist. Enforcement is also deferred. Compliance is frequently checked after the fact through audits, inspections, reports, inquiries, litigation, supervisory review, or certification cycles. This may be acceptable for low-speed administrative processes, but it is insufficient for AI agents, autonomous vehicles, drones, real-time disaster response, financial risk signals, digital identity decisions, infrastructure telemetry, public health thresholds, and cyber-physical systems. By the time a deferred review identifies failure, harm may already have propagated across systems. Enforcement is disjointed. The legal rule may sit in one document. The compliance checklist may sit in another system. The operational workflow may run in a proprietary platform. The data may sit in a cloud database. The credential may be issued by a separate identity system. The AI model may run in an external environment. The audit record may exist as a PDF. The public report may appear on a dashboard. These parts rarely share a single proof structure. As a result, institutions cannot reliably reconstruct the chain from rule to input, computation, output, credential, decision support, and correction. Enforcement is often opaque. A platform may indicate that a requirement was satisfied, a model may produce a risk score, a dashboard may show readiness, or a credential may appear valid, but the path from rule to execution to outcome is not transparent. What rule version was used? Which data was processed? Which model influenced the output? Which compute environment ran the check? Which actor authorized the call? Which credential was active? Which jurisdictional fork applied? Which public-safe rule governed publication? Which proof receipt was generated? Which downstream systems consumed the result? Without these answers, governance remains dependent on trust in systems whose internal behavior may be hidden. As AI agents, autonomous systems, software-defined infrastructure, distributed compute, digital public infrastructure, and automated governance workflows expand, this legacy model becomes untenable. Critical systems require execution infrastructure that is deterministic where determinism is required, probabilistic only where uncertainty is explicitly governed, tamper-evident, auditable, jurisdiction-aware, privacy-preserving, and tied to human-authored and institutionally governed policy logic. They require proof that a rule was applied, not merely a claim that a rule existed. They require execution environments that preserve confidentiality, integrity, provenance, and correctionability. They require machine-verifiable records that can support credential issuance, simulation review, public-safe reporting, regulatory inspection, insurance analysis, finance-readiness review, and institutional oversight without turning technical outputs into unbounded authority. The NSF Compute Layer is engineered to address this execution problem. It is not generalized cloud compute. It is not a blockchain execution engine. It is not a regulatory automation platform. It is not an AI model host alone. It is the governance-bound compute substrate of the Nexus Sovereignty Framework: the layer where Smart Clauses, evidence objects, credentials, simulations, AI constraints, public-safe rules, and proof receipts are evaluated under controlled, verifiable, and correctionable conditions. The core doctrine is: **The NSF Compute Layer makes governance computable, verifiable, and auditable without converting computation into sovereign authority.** ### Role of the Compute Layer The NSF Compute Layer serves as the execution and verification substrate for the Nexus Sovereignty Framework. It sits between the Data Layer, where evidence and state are stored, and the Audit, Registry, Credential, Simulation, AI, and Public-Safe Reporting layers, where results are recorded, interpreted, routed, and corrected. Its task is to ensure that when a clause, model, simulation, credential rule, access policy, public-safe transformation, or readiness check is evaluated, the evaluation occurs under a governed compute profile and produces a proof-bound record. The first function of the Compute Layer is orchestration. It determines how a Smart Clause, simulation, AI control, credential rule, or validation workflow should run, where it should run, which data it may access, which execution environment is required, which actor or machine identity invoked it, which jurisdiction applies, which output class is permitted, and which proof receipt must be generated. Orchestration is not merely job scheduling. It is governance-aware workload placement. The second function is isolation. Sensitive governance computation must often be separated from the host environment, platform operator, cloud administrator, vendor support channel, unauthorized users, other workloads, and external networks. Isolation may be achieved through Trusted Execution Environments, confidential computing, secure enclaves, hardened containers, controlled rooms, sovereign compute nodes, air-gapped environments, secure edge runtimes, zero-knowledge circuits, or simulation sandboxes. The correct isolation method depends on the data class, risk level, jurisdiction, threat model, and downstream use. The third function is proof generation. Every material execution should produce a structured proof object. This may be a Clause-Attested Compute record, proof receipt, simulation receipt, credential validation receipt, zero-knowledge proof bundle, model evaluation receipt, access receipt, public-safe transformation receipt, or compute attestation. The proof object should state what ran, which version ran, which inputs or input commitments were used, which environment executed the workload, which output was produced, what the proof proves, what it does not prove, and how the result can be challenged or corrected. The fourth function is boundary preservation. The Compute Layer must prevent technical outputs from becoming unbounded claims. A clause pass result may support review, credential issuance, readiness status, or routing, but it does not automatically certify compliance, approve finance, underwrite insurance, issue public warnings, enforce treaties, command emergency response, or determine legal liability. The Compute Layer should carry proof-scope metadata so that every downstream consumer understands what the execution result means. The fifth function is continuity. Compute environments change. Models update. Hardware fails. Cloud providers change terms. TEEs are patched. Cryptographic methods evolve. Nodes go offline. Jurisdictions change rules. The Compute Layer must preserve enough execution metadata to support replay, audit, migration, correction, and intergenerational verifiability. A system must be able to determine years later which clause version ran, which model version contributed, which data object was used, which environment was active, and whether the result remains current, corrected, disputed, or superseded. The Compute Layer therefore transforms governance from static declaration into verifiable computation, but always with institutional discipline. It does not replace lawful decision-makers. It strengthens the evidentiary infrastructure available to them. ### Governance-Bound Compute The NSF Compute Layer is governance-bound compute. This phrase is central. General compute answers the question: can a workload run? Governance-bound compute answers a deeper question: may this workload run, under which authority, against which data, in which jurisdiction, with which credentials, inside which environment, producing which output, under which proof scope, and subject to which correction path? A standard cloud platform may optimize for performance, scale, elasticity, price, and developer convenience. A blockchain virtual machine may optimize for deterministic consensus and transaction execution. An HPC cluster may optimize for throughput, simulation scale, accelerator utilization, and scientific performance. An edge device may optimize for latency and local control. An AI inference platform may optimize for model serving. These are important capabilities, but they are not sufficient for sovereign governance. Governance-bound compute adds policy context to compute. It requires every material workload to be connected to a clause, evidence profile, data classification, access policy, actor identity, machine identity, jurisdictional scope, runtime profile, logging requirement, proof receipt, and boundary statement. A workload cannot simply access data because it is technically able to do so. A model cannot simply call a tool because the API exists. A simulation cannot simply export a result because the run completed. A credential cannot be issued simply because a platform says the workflow passed. The Compute Layer enforces the conditions under which computation becomes acceptable evidence. This is particularly important for AI agents and autonomous systems. An AI agent may be able to retrieve data, write code, call APIs, generate reports, trigger workflows, modify records, or interact with external services. In NSF, the agent’s compute context must define its identity, permissions, tool boundaries, memory policy, data access class, output class, human review requirements, and kill-switch conditions. Its actions should generate proof records when material. Without governance-bound compute, agentic AI becomes a sovereignty risk. Governance-bound compute is also essential for Project SPVs and national risk portfolios. A Project SPV evidence workflow may involve asset telemetry, environmental safeguards, engineering data, climate simulations, financial-readiness evidence, insurance-readiness evidence, and public-safe reporting. The Compute Layer must ensure that each computation uses authorized evidence, preserves confidentiality, produces proof receipts, and does not overstate its downstream meaning. This is how NSF makes computation accountable to institutional logic rather than allowing computation to quietly become institutional logic. ### Execution Environments and Compute Profiles The NSF Compute Layer should support multiple execution environments because no single compute technology can serve all use cases, jurisdictions, threat models, latency needs, and data sensitivities. The Framework should define compute profiles, each with defined security, sovereignty, audit, performance, and proof requirements. A standard governed runtime profile may be appropriate for low-sensitivity public data, public reference clauses, non-confidential validation, open simulation templates, or educational use. It should still include workload identity, logs, versioning, and proof receipts, but it may not require hardware isolation. A secure enclave profile may be required when sensitive inputs must be shielded from host systems. This may involve Intel SGX, AMD SEV, ARM TrustZone, confidential virtual machines, enclave-based runtimes, or equivalent technologies. The goal is to ensure that workload code and data are protected from unauthorized host access and that outputs can be attested. A confidential compute profile may be appropriate for cloud or sovereign cloud environments where workloads require memory encryption, measured boot, remote attestation, key release controls, and administrator isolation. Confidential computing can support compute-to-data across environments where data owners require proof of execution integrity before releasing protected data into a workload. A controlled-room compute profile may be required for data that cannot leave a legal or institutional environment and should be processed only under supervised conditions. This may apply to health data, national security-sensitive records, community knowledge, regulated financial evidence, Project SPV confidential data, or protected-source information. The compute environment may be physically, logically, or procedurally controlled, and outputs may require review before release. A zero-knowledge compute profile may be used where the objective is to prove that a computation or condition was satisfied without revealing underlying inputs. This may involve zkSNARKs, STARKs, proof-carrying data, selective disclosure, range proofs, membership proofs, or other privacy-preserving methods. ZK computation is not appropriate for every workload, but it is powerful for credential validation, threshold satisfaction, restricted compliance evidence, and privacy-preserving cross-border verification. A federated simulation profile may be used where model runs must occur across multiple data zones or compute nodes without centralizing raw data. National datasets may remain inside Sovereign Data Zones while local compute produces proof-bound outputs for regional or global aggregation. A high-performance compute profile may be required for climate models, disaster simulations, digital twins, multi-agent simulations, infrastructure stress tests, geospatial processing, AI evaluation, and national or regional risk portfolios. HPC profiles should include workload provenance, model versioning, data locality, output classification, energy and resource metadata where relevant, and proof receipt generation. An edge execution profile may be required for drones, sensors, mobile devices, field inspection tools, AI-RAN deployments, industrial controllers, disaster response kits, ships, vehicles, and offline environments. Edge profiles must handle local identity, signed logs, cached clause logic, limited connectivity, tamper detection, delayed synchronization, and safe-mode behavior. An offline or degraded-mode profile may be necessary for crisis environments. It should define which clauses can be evaluated offline, how long cached credentials remain valid, what actions require later reconciliation, what proof records must be preserved locally, and which high-consequence actions must be blocked or routed to human review if authoritative state cannot be reached. By defining compute profiles, NSF avoids over-reliance on any single technology. TEEs, zero-knowledge proofs, confidential computing, secure enclaves, HPC, edge runtimes, and controlled rooms each have roles. The Framework should select the right execution environment based on governance risk. ### Trusted Execution Environments Trusted Execution Environments are an important but bounded part of the NSF Compute Layer. A TEE is a protected execution environment designed to isolate code and data from the broader host system. It can support code integrity, data confidentiality, remote attestation, secure key release, and tamper-evident execution records. TEEs are useful where an institution needs evidence that a defined workload ran inside a measured environment and that the host operator could not easily inspect or alter the computation. NSF may support several TEE and confidential compute backends, including hardware enclave technologies, confidential virtual machines, secure elements, trusted platform modules, secure boot chains, enclave-oriented runtimes, WebAssembly-based isolation frameworks, hardened containers with attestation, sovereign cloud confidential compute, and simulation environments that emulate TEE properties for lower-assurance contexts. Examples may include Intel SGX, AMD SEV-SNP, Intel TDX, ARM TrustZone, Nitro Enclaves-style models, Enarx-like approaches, WebAssembly sandboxing, TPM-backed attestation, and other evolving confidential compute technologies. However, NSF must avoid TEE absolutism. A TEE can support execution integrity, but it cannot prove that the clause was legally correct, that the model was unbiased, that input data was truthful, that the result should have legal effect, or that the system is safe in every context. TEEs have threat models, side-channel risks, patch requirements, vendor dependencies, hardware lifecycle issues, attestation chain dependencies, and jurisdictional concerns. They must be used as one control within a broader architecture. A TEE-supported CAC should therefore state its proof scope precisely. It may prove that a specific workload hash ran in a measured environment, with a specific attestation, at a specific time, against specified input commitments or data references, producing a specific output. It should not claim more than that. If legal, regulatory, financial, insurance, or public authority meaning is attached to the result, that meaning must come from separate institutional adoption or lawful instruments. TEE selection must also be sovereignty-aware. A national system may require local key custody, local attestation authority, local administrator boundaries, controlled support access, and domestic or trusted regional hosting. A cloud-based confidential compute environment may be technically strong but sovereignty-weak if keys, telemetry, logs, or legal exposure are externally controlled. NSF compute profiles must therefore evaluate not only cryptographic isolation, but also sovereign control. In NSF, TEEs are instruments of proof. They are not substitutes for governance. ### Confidential Computing, Secure Enclaves, and Sovereign Compute Confidential computing extends the TEE idea into broader infrastructure. It aims to protect data in use, not only at rest or in transit. This is crucial for compute-to-data, sovereign cloud, federated HPC, AI inference, secure simulations, and sensitive public-sector workflows. A confidential computing environment may allow a data owner to release data only to a measured workload whose identity and integrity can be verified. The workload can run analytics, validation, simulation, or AI inference without exposing raw data to the infrastructure operator. Outputs can be signed and classified before release. This pattern is central to NSF because it enables cooperation without blind trust in the host environment. Secure enclaves are useful for credential validation, privacy-preserving analytics, controlled risk scoring, public health threshold checks, secure multiparty review, cross-border evidence verification, and Project SPV diligence workflows. They can help an insurer, development bank, regulator, public authority, or technical validator review evidence without extracting raw data from a Sovereign Data Zone. They can also help AI models operate under controlled access to sensitive data without sending prompts and outputs into unmanaged environments. Sovereign compute requires more than confidential computing. It requires control over where workloads run, who administers them, who holds keys, how telemetry is handled, where logs reside, how backups are managed, how support access is governed, how recovery works, and how exit occurs. A workload can run inside an enclave and still fail sovereignty if the enclave is controlled by an external vendor without meaningful local governance. The NSF Compute Layer should therefore distinguish between secure execution and sovereign execution. Secure execution concerns technical protection. Sovereign execution concerns lawful, jurisdiction-aware, institutionally controlled computation. The strongest deployments require both. ### Zero-Knowledge Execution and Privacy-Preserving Compute Zero-knowledge execution and privacy-preserving proof systems allow a party to prove that a condition was satisfied or a computation was performed without revealing underlying data. These methods are powerful in NSF because many governance processes require verifiability without exposure. Zero-knowledge proofs can support credential validation, eligibility checks, threshold satisfaction, sanctions screening, emissions reporting, public health aggregation, refugee protection workflows, age or qualification proofs, confidential compliance evidence, and restricted Project SPV diligence. They can help a party prove that a clause condition was satisfied without revealing personal data, proprietary data, community-sensitive data, or security-sensitive details. A refugee processing clause may prove that intake requirements were followed without exposing protected identities to unauthorized actors. A health credential process may prove vaccination or testing status without revealing unnecessary medical detail. An emissions workflow may prove that a threshold condition is satisfied without disclosing proprietary production data. A parametric risk workflow may prove that satellite-derived or sensor-derived hazard conditions met a defined trigger without releasing full-resolution imagery or commercially sensitive datasets. A financial integrity workflow may prove screening occurred without revealing all underlying records to every counterparty. NSF should support ZK-enabled clause types and proof bundles, but with clear boundaries. A zero-knowledge proof proves a formal statement under a defined circuit, method, or commitment. It does not prove that the legal rule was correctly chosen, that the source data was truthful, that the governance context was sufficient, or that downstream legal or financial action is authorized. The proof must therefore be linked to proof scope, clause identity, data class, issuer or verifier identity, time window, jurisdiction, and correction path. ZK proofs can also support proofs of simulation. Complex simulations may be too large to reproduce by every verifier, or may rely on sensitive data. A proof bundle can summarize that a simulation was executed according to a defined model, parameter set, and input commitments, while revealing only approved outputs. This is especially relevant for climate, disaster, infrastructure, and public health modeling across sovereign datasets. Zero-knowledge computation enables verification without extraction. It is one of the key technologies that allows NSF to preserve privacy and sovereignty while supporting cross-border trust. ### Clause Execution Workflow A mature NSF clause execution workflow begins with a clause call. The caller may be a human user, institutional system, AI agent, smart contract, credential issuer, public authority workflow, Project SPV system, sensor network, edge device, digital twin, simulation engine, or autonomous system. The call must identify the clause, purpose, actor, machine identity where relevant, jurisdictional context, requested output type, and required proof profile. The second step is authorization. The Compute Layer checks whether the caller has the required credentials, role, standing, purpose, and jurisdictional authority to invoke the clause. If the caller is an AI agent, the system also checks tool permissions, memory policy, model identity, and agent scope. If the clause concerns sensitive data, the system checks whether the requested execution is permitted under the relevant data classification and Sovereign Data Zone rules. The third step is data binding. Inputs are requested from the Data Layer through policy-aware interfaces. The Data Layer verifies source identity, provenance metadata, schema compatibility, data classification, temporal validity, spatial scope, quality indicators, public-safe status, and clause compatibility. If data is missing, stale, incompatible, restricted, or disputed, the execution may halt, return insufficient evidence, or route to review. The fourth step is environment selection. The Compute Layer selects an execution environment that meets the clause’s compute profile. A low-risk public clause may run in a standard governed runtime. A sensitive health clause may require a confidential compute environment. A national security-sensitive workflow may require a controlled room. A geospatial simulation may require HPC. A privacy-preserving credential check may require ZK proof generation. An edge mission may require local runtime with later synchronization. The fifth step is environment provisioning. The workload is instantiated with signed code, dependency hashes, runtime policy, secrets management, key release controls, logging configuration, output restrictions, and attestation requirements. If the environment cannot satisfy the clause profile, the workflow should fail safely or route to fallback. The sixth step is execution. The clause runs under controlled conditions. Deterministic clauses should produce reproducible technical outputs under the same inputs and environment. Probabilistic models or simulations should record seeds, parameters, uncertainty, and model versions. AI-supported clauses should record model identity, retrieval context, tool calls, prompt profiles where appropriate, and human review gates. The seventh step is output classification. The result is not merely returned. It is classified. The system determines whether the output is pass, fail, trigger, review required, insufficient evidence, disputed, provisional, public-safe, restricted, stale, superseded, or corrected. It determines whether the output may be published, shared, stored, used for credential issuance, routed to a public authority, or restricted to a controlled room. The eighth step is proof generation. The execution creates a CAC record or proof receipt containing clause identity, version, input references or commitments, execution environment, actor identity, credential state, timestamp, output, proof scope, and correction path. If a TEE, ZK system, or confidential compute environment was used, the proof includes relevant attestation or proof bundle. The ninth step is storage and propagation. The result is stored in the Audit Layer, linked to the originating clause, input objects, credential outcomes, simulation records, public-safe outputs, and registry status. Propagation depends on data class. Public proof metadata may be broadly visible. Sensitive records may remain in an SDZ. Credential status may be published through a status list. A public-safe output may be released only after review. The tenth step is lifecycle management. The record remains status-aware. It may later be corrected, superseded, disputed, revoked, or linked to a new clause version. Downstream consumers must be able to detect status changes. This workflow ensures that execution is not a black box. It is a governed lifecycle from clause call to proof receipt to correction. ### Clause-Attested Compute: Core Structure Clause-Attested Compute is the canonical execution record produced when a clause-linked computation is performed under NSF. It is not merely a log entry. It is a structured proof envelope designed for machine verification, institutional review, public-safe interpretation, and long-term audit. A CAC should include a unique identifier, clause identifier, clause version, clause fork, source authority, jurisdictional context, caller identity, actor credentials, machine or agent identity where relevant, execution purpose, input references, input commitments, input classifications, provenance references, schema versions, data quality indicators, compute environment identity, runtime profile, workload hash, dependency hashes, model version where relevant, TEE or confidential compute attestation where used, zero-knowledge proof reference where used, timestamp, temporal validity, output result, output classification, proof scope, public-safe status, downstream routing, credential effects where applicable, audit references, storage location, correction path, dispute status, and supersession state. The CAC should distinguish between input references and raw inputs. Sensitive inputs may not be stored inside the CAC. Instead, the CAC may contain hashes, commitments, access-controlled pointers, or zero-knowledge proof references. This allows verification without exposing protected data. The CAC should also distinguish between execution result and institutional effect. A result may show that a clause condition passed. That does not automatically mean a credential must be issued, a payment must be made, a license must be suspended, a public warning must be issued, or a legal conclusion has been reached. The effect field should state whether the result is advisory, validation-supporting, credential-supporting, readiness-supporting, review-triggering, public-safe, restricted, authority-dependent, or operationally binding under a separate instrument. The CAC should be independently auditable. A verifier should be able to check the clause hash, signature, actor credential, environment attestation, input commitments, output signature, proof receipt schema, and status. Depending on access rights, the verifier may not see raw inputs. This is essential for privacy, sovereignty, and controlled disclosure. The CAC should be non-repudiable in the limited technical sense that a signed record can identify the system or actor that produced it and detect tampering. It should not be described as non-repudiable in a legal sense without jurisdiction-specific qualification. Legal non-repudiation depends on applicable law, identity systems, signature rules, and institutional procedures. The CAC is the bridge between computation and governance memory. It tells future reviewers what happened, under which rule, with which evidence, in which environment, and with which limitations. ### CAC Verification Across Systems CAC records are designed to function as cross-system evidence. They allow a verifier in one system to inspect proof generated in another system without trusting the other system blindly or requiring unrestricted access to raw data. A credential issuer may require a CAC showing that an eligibility clause passed before issuing a verifiable credential. A regulator may inspect CAC records associated with AI agents, autonomous vehicles, aviation systems, public health workflows, financial reporting, or critical infrastructure telemetry. A development bank may review CAC-linked evidence packages for safeguards, resilience, climate adaptation, or Project SPV readiness. An insurer may examine CAC records as part of exposure, mitigation, or parametric trigger analysis by licensed actors. A regional body may compare CAC records from different national nodes to support treaty-aware reporting or cross-border coordination. A public authority may use CAC records to reconstruct a disaster readiness workflow. A technical auditor may inspect CAC records to verify runtime integrity and evidence lineage. CAC verification should require the clause identifier, clause version, proof receipt schema, signature, status record, and any required attestation or proof bundle. If the verifier has appropriate authorization, it may also inspect input records, simulation packages, model metadata, or controlled-room evidence. If not, it may verify only the proof scope, status, and commitments. This is how NSF enables interoperability without data extraction. A national system can prove that it evaluated a clause without sharing raw sovereign data. A community-controlled environment can prove that a public-safe rule was applied without exposing protected knowledge. A Project SPV can prove that required evidence exists without making all commercial data public. A public health system can prove aggregate threshold satisfaction without exposing personal records. CAC verification must also include status checks. A CAC may be active, superseded, corrected, disputed, revoked, expired, restricted, or linked to a compromised environment. A verifier should not rely on a CAC without checking current status. If a clause version is later found flawed, dependent CAC records may require annotation. If an attestation key is compromised, affected records may need review. If input data is corrected, CAC outputs may need supersession. Cross-system evidence is only trustworthy if it remains status-aware. ### ZK Proofs, Selective Disclosure, and Proof of Simulation Sensitive governance environments often require proof without disclosure. The Compute Layer should therefore support zero-knowledge proofs, selective disclosure, confidential compute, secure multiparty computation where appropriate, and proof-of-simulation bundles. A ZK-enabled clause execution may allow a party to prove that a credential condition is satisfied without revealing the underlying personal data. It may prove that emissions are below a threshold without exposing proprietary production details. It may prove that a humanitarian intake workflow met required conditions without revealing protected identities. It may prove that a risk trigger was evaluated against authentic remote sensing inputs without releasing full imagery. It may prove that a financial integrity screening occurred without exposing confidential counterparties to unauthorized actors. Proof of simulation is a related capability. A complex model may involve thousands of runs, large datasets, and sensitive inputs. Rather than requiring every verifier to rerun or inspect the entire simulation, NSF can package simulation evidence into proof bundles. These bundles may include model hashes, parameter commitments, scenario identifiers, output commitments, uncertainty summaries, verifier signatures, and selective disclosure of results. In some cases, ZK proofs may show that a simulation followed a defined procedure without revealing all inputs. However, ZK and proof-of-simulation records must remain bounded. They do not prove that the model was scientifically correct unless the method was separately validated. They do not prove that the legal rule was appropriate. They do not prove that a public authority adopted the result. They do not prove financeability, insurability, or compliance beyond the statement encoded. They prove the formal statement they are designed to prove. NSF should therefore require ZK proof receipts to include statement definition, clause reference, proof system, circuit or method version, input commitment type, verifier identity, timestamp, proof scope, limitations, and correction path. Privacy-preserving proof is powerful only when it remains interpretable. ### Determinism, Reproducibility, and Probabilistic Systems The Compute Layer must handle both deterministic and probabilistic computation. Many Smart Clauses should be deterministic. A credential status check, schema validation, threshold comparison, hash verification, access authorization, or rule-based transformation should produce the same result when the same inputs and clause version are used. Determinism supports audit, replay, dispute review, and cross-system trust. However, many NSF workloads involve probabilistic systems: AI models, statistical simulations, Monte Carlo runs, climate models, disaster forecasts, risk models, agent-based simulations, Bayesian updates, anomaly detection, remote sensing classification, and large language model outputs. These cannot always be reduced to simple deterministic logic. The Compute Layer must govern them rather than pretend they are deterministic. For probabilistic workloads, the system should record model identity, model version, parameter settings, random seeds where applicable, sampling method, input data references, uncertainty ranges, confidence intervals, calibration status, validation records, evaluation results, and known limitations. If exact replay is impossible, the system should preserve enough information for approximate reconstruction and methodological review. If an LLM is used, the system should record model version, system instructions or prompt profile where appropriate, retrieval context, tool calls, temperature or decoding parameters where available, output classification, human review state, and prohibited-use boundaries. The output of a probabilistic computation should not be treated as a binary truth unless the clause defines a clear threshold and uncertainty handling. A flood model may produce likelihood ranges. An AI classifier may produce confidence scores. A risk simulation may produce scenario distributions. A geospatial model may produce uncertain hazard boundaries. The Compute Layer must preserve uncertainty as part of the result. This is crucial for public-safe reporting and finance-readiness. A simulation output should not become a guarantee. An AI output should not become a legal determination. A model-based trigger should not be treated as certain without appropriate thresholds, confidence rules, and review conditions. Governance-bound compute does not eliminate uncertainty. It makes uncertainty explicit. ### Execution Orchestration Across Sovereign and Federated Compute The NSF Compute Layer must support dynamic execution orchestration across sovereign nodes, regional compute networks, global reference environments, enterprise evidence rooms, edge devices, controlled rooms, and HPC clusters. This orchestration must be governance-aware. A workload may be routed to a national sovereign TEE because the data cannot leave the country. A simulation may be split across several National Nexus Consortium nodes because each jurisdiction retains raw data. A regional hazard model may run in a Regional Nexus Consortium compute cluster using approved aggregate outputs from national SDZs. A global benchmark may run in a reference environment using public or synthetic data. A Project SPV evidence check may run in a controlled data room accessible to authorized reviewers. A drone mission clause may run at the edge with cached state and later synchronization. An AI model evaluation may run on a GPU cluster with strict data restrictions. The orchestration engine should consider data locality, jurisdiction, compute profile, sensitivity, latency, cost, energy, availability, attestation capability, model requirements, credential requirements, public-safe output rules, and fallback options. It should not select compute based only on speed or cost. Sovereignty, security, and proof requirements may override efficiency. Federated orchestration should support workload manifests. A manifest should define clause, data references, required compute profile, model dependencies, expected output type, proof receipt schema, access conditions, and audit requirements. Each node can execute its portion and return proof-bound outputs. The federation layer can aggregate outputs where permitted. This enables national, regional, and global risk intelligence without centralizing all data. Climate simulations, disaster forecasts, public health models, supply chain analyses, digital twin updates, AI evaluations, and infrastructure stress tests can run across distributed compute environments while preserving local control. Execution orchestration is the operational heart of sovereign compute. ### Compute Attestors and Execution Assurance The Compute Layer should define a Compute Attestor role. A Compute Attestor is not a regulator, certification body, or public authority by default. It is a role that supports verification of execution environment integrity under defined NSF profiles. A Compute Attestor may verify that a runtime environment meets a required profile, that an enclave attestation is valid, that workload hashes match approved versions, that latency thresholds are met for response-critical systems, that logs are active, that key release policies are correct, that a compute node is registered and in good standing, that a simulation environment used the correct model container, or that an edge runtime preserved signed records during offline operation. Compute Attestors may be public authorities, national technical bodies, accredited laboratories, university labs, regional technical nodes, qualified providers, validator quorums, or internal institutional roles, depending on domain and governance context. Their authority must be scoped. A compute attestor for HPC simulation integrity does not automatically have authority over health data access. A provider attesting its own environment may need independent review for high-risk workflows. A public authority attestor may operate under domestic law. Attestation records should include attestor identity, credential status, environment inspected, profile assessed, evidence reviewed, date, validity period, limitations, and revocation path. If an attestation is later revoked or an environment compromised, affected CAC records should be identifiable. This role enables compute market integration without sacrificing governance. Third-party compute providers, sovereign cloud operators, HPC centers, edge infrastructure providers, and enterprise nodes can offer compute capacity if they meet NSF profiles and produce verifiable attestation records. Participation in compute provision does not grant governance authority. It grants a scoped execution capability subject to audit and correction. Compute Attestors help answer a basic question: not only did code run, but did it run in an environment fit for the governance purpose? ### Compute Market Integration Without Governance Capture The Compute Layer may integrate with compute markets, distributed compute networks, institutional testbeds, GPU and CPU pools, sovereign cloud providers, university HPC centers, regional simulation grids, and edge infrastructure networks. This is necessary because national, regional, and global risk portfolios require substantial compute capacity for simulation, AI evaluation, digital twins, geospatial processing, and real-time analytics. However, compute market integration must not create governance capture. A compute provider should not gain authority over clause meaning, credential legitimacy, public-safe reporting, finance-readiness, insurance-readiness, or public-good standards simply because it provides compute capacity. Compute is a service. Governance remains role-bound, institutionally governed, and proof-constrained. NSF should define registered compute pools with clear profiles. Providers may offer CPU, GPU, accelerator, storage, edge, confidential compute, TEE, HPC, or simulation capacity. Each provider should have node identity, jurisdiction, security profile, attestation capability, data classes permitted, uptime records, incident history, energy profile where relevant, cost model, key management profile, and exit conditions. Workloads should be matched to compute providers only if governance requirements are satisfied. Compute markets may include decentralized or distributed networks, but NSF must avoid tokenized governance dependencies. Payment for compute services may occur through lawful service models, institutional contracts, grants, public funding, enterprise procurement, or other legal mechanisms. Governance rights should not be tied to compute market stake. Dynamic compute provisioning is powerful for resilience. During a regional disaster, simulation workloads may need to burst into regional or global compute pools. During public health emergencies, secure analytics may need additional capacity. During climate stress testing, HPC resources may need to run large-scale models. NSF can support this while preserving data locality, proof receipts, and output controls. The principle is simple: compute capacity may be market-provided, but governance authority must remain public-good, role-bound, and record-governed. ### Execution Policies and Governance Hooks Every Smart Clause should carry execution policies. These policies define where, how, by whom, under what conditions, and with what safeguards the clause may be evaluated. Execution policy is the mechanism that binds compute to governance. Execution policies may specify required compute profile, approved jurisdictions, permitted data classes, prohibited data classes, required enclave type, required attestation, approved model versions, credential requirements, human review conditions, simulation preconditions, fallback logic, logging requirements, public-safe output rules, key management requirements, latency requirements, offline operation rules, and correction pathways. A public health clause may require execution inside a national SDZ or controlled health data environment, with privacy-preserving outputs and public authority review. A disaster readiness clause may allow regional execution using aggregate data but require public-safe output review before publication. An AI agent tool-use clause may require sandbox execution, prompt and output logs, and human approval for high-impact outputs. A financial-readiness clause may require controlled-room computation and prohibit public claims of financeability. A drone mission clause may require edge execution with local logs, geofence constraints, and later synchronization. A climate simulation clause may require HPC execution with model version records and uncertainty output. Fallback logic is essential. If a required enclave fails, the clause may halt, route to human review, use a lower-assurance fallback for advisory-only output, revert to prior safe mode, or delay execution. If authoritative state is unavailable, an edge device may use cached rules only within a defined time window. If a model version is suspended, the workflow must block or use an approved replacement. If data is missing, the result may be insufficient evidence rather than fail. Execution policies should be updated through governed processes. The original text referred to DAOs controlling execution parameters. In the mature NSF framework, this should be reframed as role-bound governance through councils, validator quorums, competent authorities, registries, controlled rooms, contribution-aware review bodies, and recorded governance processes. DAO tooling may be used where appropriate, but it should not be the constitutional source of authority. Execution policies ensure that compute is not only secure. It is institutionally governed. ### Compute Layer for AI Agents and Autonomous Systems The Compute Layer is central to governing AI agents and autonomous systems. These systems do not merely process data. They can make recommendations, call tools, retrieve records, generate documents, issue commands, interact with APIs, modify workflows, and influence real-world decisions. Without compute governance, they become uncontrolled execution surfaces. In NSF, an AI agent should run under a bounded execution policy. The policy should define agent identity, model identity, permitted tools, permitted data classes, memory rules, retrieval constraints, output classes, human review gates, logging requirements, prohibited actions, timeout limits, and kill-switch conditions. Agent actions should generate proof records when material. Tool calls should be logged and linked to clause context. Outputs should be classified. Sensitive outputs should not be published without public-safe review. High-consequence actions should route to competent human or institutional review. Autonomous systems such as drones, robots, industrial controllers, AI-RAN controllers, logistics optimizers, and digital twin-driven control systems require similar constraints. A drone mission should be evaluated against airspace clauses, weather clauses, operator credentials, mission scope, privacy rules, and public authority context. An AI-RAN controller should be evaluated against network security, public safety, telemetry governance, degraded-mode rules, and model behavior constraints. An industrial controller should operate within safety thresholds, maintenance rules, incident response logic, and manual fallback conditions. The Compute Layer should prevent agents from silently crossing from decision support into execution authority. A model may recommend, classify, simulate, summarize, or route, but the legal or operational effect must remain bounded by clause policy and institutional authority. If an AI agent produces a finance-readiness summary, it must not present investment advice. If it produces an insurance-readiness analysis, it must not underwrite. If it summarizes public health data, it must not issue official guidance unless adopted by competent authorities. If it maps hazards, it must not create public warnings outside authority. AI sovereignty requires compute sovereignty. The model must operate inside governed execution conditions. ### Compute Layer for Digital Twins and Simulation Digital twins and simulations require specialized compute governance. A digital twin is not merely a visual model. It is a stateful representation of assets, environments, infrastructure, populations, hazards, services, systems, or portfolios across space and time. It may influence planning, finance-readiness, insurance analysis, public-safe reporting, disaster response, infrastructure maintenance, and public authority review. The Compute Layer must ensure that digital twin updates are evidence-linked. When a twin state changes, the system should record which data updated it, which model processed it, which simulation ran, which assumptions applied, which uncertainty existed, which public-safe rules govern outputs, and which downstream records depend on the state. Simulation workloads should preserve reproducibility where feasible. Climate models, disaster scenarios, infrastructure stress tests, agent-based models, Monte Carlo simulations, Bayesian risk models, hydrological models, epidemiological models, supply-chain models, and financial stress simulations each require model identity, version, parameters, input references, output classifications, and proof receipts. Simulation outputs should not be confused with prediction certainty. A simulation is evidence under assumptions. The Compute Layer should preserve assumptions and uncertainty. It should also support comparison across versions. If a clause upgrade changes a disaster trigger, simulations should compare old and new outcomes. If a climate model is updated, previous Project SPV records may need annotation. If a digital twin uses corrected asset data, dependent reports should be flagged. Federated simulation is particularly important. National datasets may remain local while regional or global simulations use distributed computation. The Compute Layer should orchestrate local runs, generate local proof receipts, aggregate allowed outputs, and preserve lineage. Simulation without proof becomes opinion. Proof without simulation becomes brittle. NSF requires both. ### Compute Layer for Credentials and Access Decisions Credential issuance, validation, renewal, suspension, and revocation depend on compute. A credential should not be issued merely because a form was submitted. It should be linked to evidence, clause logic, issuer authority, validation checks, and proof receipts. The Compute Layer evaluates credential clauses. It checks eligibility, evidence completeness, issuer authority, subject identity, expiry rules, revocation conditions, renewal logic, jurisdictional scope, and dependency credentials. It may run in standard governed runtime, secure enclave, zero-knowledge proof environment, or controlled room depending on sensitivity. For example, a professional qualification credential may require training records, issuer accreditation, exam evidence, identity proof, and jurisdictional recognition. A disaster response credential may require organizational standing, training, location, mission scope, and safety constraints. A health credential may require privacy-preserving evidence and public health authority context. A Project SPV readiness credential may require asset evidence, monitoring data, safeguard status, and proof receipts. Access decisions are also compute-bound. A user, institution, machine, model, or agent requesting access to data should be evaluated by access-control clauses. The Compute Layer checks identity, role credential, purpose, data class, jurisdiction, public-safe status, and consent or authority where applicable. It returns allow, deny, review required, restricted, insufficient authority, or degraded-mode status. The access decision itself should generate a proof record. This is crucial for zero trust. No actor should access sensitive data merely because it is technically connected. Access is a computed governance decision, and that decision must be auditable. ### Compute Layer for Finance-Readiness and Insurance-Readiness The Compute Layer can support finance-readiness and insurance-readiness evidence, but it must do so with strict boundary controls. Risk and innovation portfolios require reliable computation for hazard modeling, asset exposure, climate stress testing, resilience monitoring, Project SPV evidence, parametric trigger analysis, maintenance records, and safeguards review. These computations can make evidence more usable for development banks, insurers, investors, regulators, and public authorities. However, the Compute Layer must not generate investment advice, underwriting decisions, ratings, finance approval, insurance approval, procurement approval, or claims of financeability or insurability by itself. It can generate proof-bound evidence. Licensed or competent actors decide how to use that evidence. A finance-readiness computation may validate that required project evidence exists, that climate scenarios were run, that public-safe reports are linked to source records, that asset telemetry is current, that safeguards records are complete, or that a Project SPV evidence package meets a defined data profile. It does not approve financing. An insurance-readiness computation may validate hazard data, exposure records, parametric trigger inputs, mitigation measures, maintenance logs, and claims-data readiness. It does not underwrite insurance or bind coverage. This boundary must be embedded in execution policies and output classification. Results should be labeled as readiness support, evidence support, review support, or restricted technical output. Public-facing outputs should avoid language that implies financial endorsement. The Compute Layer makes risk evidence more computationally rigorous. It does not become a financial actor. ### Audit, Observability, and Execution Telemetry The Compute Layer must be observable. Every material workflow should generate logs, traces, metrics, and proof records sufficient for audit, incident response, correction, and continuous improvement. Execution telemetry should include workload identity, clause identity, runtime environment, node identity, data access events, credential checks, model calls, tool calls, output classification, errors, fallback events, human review gates, attestation events, proof generation, storage references, and downstream routing. OpenTelemetry-compatible tracing may be used for technical observability, but NSF must extend observability with governance metadata. Audit logs should be tamper-evident, access-controlled, classified, and linked to proof receipts. They should not expose sensitive data unnecessarily. Logs can be sensitive because they reveal who accessed what, when, for what purpose, and under which jurisdiction. The Data Layer and Compute Layer must protect logs as governance records. Observability also supports performance and resilience. Response-critical workflows may require latency thresholds. Disaster systems may require uptime targets. Edge devices may require synchronization windows. HPC simulations may require resource utilization and reproducibility metadata. AI systems may require monitoring for drift, hallucination, tool misuse, and policy violations. The Audit Layer consumes Compute Layer records, but the Compute Layer must produce them correctly. A system that cannot be observed cannot be governed. ### Failure Modes and Safe Execution The Compute Layer must assume failure. Enclaves fail. Attestation services go down. Data is missing. Credentials expire. Models are suspended. Nodes disconnect. Edge devices lose connectivity. Simulations exceed resource limits. AI agents produce unsafe outputs. ZK proofs fail. Key material is rotated. A jurisdiction blocks transfer. A public-safe output is challenged. Every clause execution policy should define failure behavior. If input data is missing, the system may return insufficient evidence. If a credential is expired, it may return review required or deny. If a TEE fails attestation, execution should halt or route to an approved fallback. If a model is suspended, the system should block model-dependent execution. If connectivity is unavailable, edge execution may proceed only within defined cached-state limits. If public-safe review is required and unavailable, publication should be withheld. If a ZK proof cannot be generated, the workflow should not reveal raw data as a shortcut without authorization. Safe execution means failure is visible and bounded. It should not silently produce false confidence. It should not default to approval. It should not convert uncertainty into pass. It should not expose data to work around compute constraints. It should not hide technical failure behind a clean dashboard. Failure records are also learning records. Repeated failures may indicate data quality issues, unrealistic clauses, insufficient compute capacity, bad model design, weak edge infrastructure, poor credential governance, or jurisdictional friction. The Compute Layer should feed failure analysis into continuous upgrade. A trustworthy execution layer is not one that never fails. It is one that fails safely, records failure, and supports correction. ### Security Architecture of the Compute Layer The Compute Layer must be secured under zero-trust assumptions. No host, network, administrator, workload, model, agent, device, cloud, vendor, or node is trusted by default. Security controls should include workload identity, signed workloads, secure boot, measured boot, remote attestation, secrets management, key isolation, least privilege, privileged access management, runtime policy enforcement, container security, vulnerability scanning, SBOM integration, SLSA provenance, dependency verification, network segmentation, encrypted communication, logging, anomaly detection, incident response, and recovery. Runtime security should detect unauthorized code changes, dependency drift, unexpected network calls, data exfiltration attempts, privilege escalation, side-channel indicators where possible, model misuse, prompt injection, tool abuse, and abnormal access patterns. AI workloads require additional controls because model prompts, outputs, embeddings, retrieval sources, and memory states can leak sensitive data. Supply-chain security is essential. A clause execution engine is only as trustworthy as its code, dependencies, build process, deployment pipeline, and runtime configuration. NSF should require signed builds, SBOMs, reproducible builds where feasible, vulnerability records, patch status, dependency policies, and secure update processes. Key management is central. Workload keys, signing keys, attestation keys, credential issuer keys, node keys, and encryption keys must be governed. Sovereign systems should control key custody. Threshold signing, HSMs, KMS policies, key rotation, revocation, recovery, and post-quantum transition planning should be supported. The Compute Layer is a high-value target. If compromised, it can distort proof receipts, leak data, manipulate outputs, or undermine institutional trust. Security must therefore be embedded, not added later. ### Governance of Compute Nodes Compute nodes are governance actors in the NSF infrastructure. They run workloads that may affect credentials, simulations, public-safe reports, readiness records, AI outputs, and institutional review. Each node must have identity, scope, status, and accountability. A compute node record should identify operator, jurisdiction, hosting environment, compute profile, hardware type, enclave capability, confidential compute capability, HPC capacity, edge role, data classes permitted, key custody, attestation methods, security posture, uptime history, incident history, audit status, software versions, supported clauses, model hosting capability, public-safe output restrictions, and suspension pathway. Different node types serve different functions. A national sovereign compute node may run domestic data-sensitive workloads. A regional compute node may run cross-border simulations. A global reference node may run benchmark tests. A controlled-room node may support sensitive review. An edge node may run mission-critical local clauses. An enterprise node may support Project SPV implementation. An academic node may run model validation or simulation research. A public-good archive node may preserve non-sensitive proof artifacts. Node authority must be scoped. Operating a compute node does not grant authority over the meaning of clauses. A cloud provider does not become a regulator. A regional compute node does not override national data policy. An enterprise compute node does not create public-good endorsement. A high-uptime node does not gain governance power by performance alone. If a node is compromised, misconfigured, stale, or operating outside scope, it should be suspended or restricted. Affected records should be flagged. Workloads may need rerun. Proof receipts may need annotation. Node governance is therefore part of execution integrity. ### Compute Layer Across GNC, RNC, and NNC Infrastructure The Compute Layer is deployed across the Nexus multiscale architecture. At the national level, National Nexus Consortiums can operate or coordinate sovereign compute environments, national TEEs, secure enclaves, National Data Rooms, public authority compute nodes, national HPC resources, edge response infrastructure, and compute-to-data environments. These support domestic sovereignty, national risk registers, digital public infrastructure, public health, disaster response, critical infrastructure, and national Project SPV evidence. At the regional level, Regional Nexus Consortiums can operate regional compute relays, federated simulation clusters, shared HPC environments, treaty-aware modeling environments, cross-border hazard simulations, regional proof verification, and regional public-safe reporting workflows. These support risks that cross borders, such as river basins, disease pathways, energy corridors, food systems, trade routes, migration flows, climate hazards, telecom infrastructure, and financial contagion. At the global level, the Global Nexus Consortium can maintain reference compute profiles, interoperability tests, proof schemas, benchmark simulations, global learning loops, and standards evolution. The global layer should not centralize sovereign-sensitive computation by default. It should support reference architecture and comparability. At the enterprise layer, National Consortium Companies, Project SPVs, qualified providers, operators, insurers, investors, and contractors may use NSF-compatible compute environments for lawful delivery. Their compute results support evidence and readiness, not public authority or financial approval by themselves. This architecture allows compute capacity to scale without centralizing control. It enables sovereign compute, regional federation, global interoperability, and enterprise implementation under one record-bound framework. ### Compute Layer Boundary Statement The NSF Compute Layer supports clause execution, simulation, credential validation, AI constraint evaluation, access decisions, public-safe transformations, proof receipts, Clause-Attested Compute records, confidential compute, zero-knowledge proofs, federated HPC, and compute-to-data workflows. It does not by itself create law, enforce treaties, certify compliance, approve finance, underwrite insurance, issue public warnings, command emergency response, approve procurement, grant public authority, determine liability, or replace competent decision-makers. Its outputs may support review, routing, readiness, evidence generation, credentialing, audit, public-safe reporting, and lawful handoff. Their legal, financial, regulatory, insurance, operational, or public authority effect depends on applicable law, institutional adoption, contractual frameworks, licensed actors, competent authorities, and governance processes. This boundary makes the Compute Layer adoptable. It allows NSF to offer powerful execution infrastructure without overclaiming institutional authority. ### The Compute Layer as the Rule Engine of the Trust Layer The NSF Compute Layer is the rule engine of the trust layer, but only in the precise sense that it evaluates governed rules under controlled conditions and produces proof-bound records. It is not generalized compute. It is not a sovereign authority. It is not a financial execution system. It is not an autonomous regulator. It is governance-bound compute for verifiable public-good infrastructure. Every execution should be traceable. Every result should be auditable. Every material output should carry proof scope. Every clause should be versioned and governed. Every machine action should be linked to human-authored and institutionally bounded policy logic. Every AI agent should operate under defined credentials, tools, memory, and review rules. Every sensitive computation should respect data sovereignty. Every cross-border output should respect jurisdictional and public-safe boundaries. Every failure should be visible. Every correction should be recordable. With the Compute Layer, NSF transforms governance from declaration into verifiable computation while preserving the distinction between computation and authority. It allows national, regional, and global actors to evaluate rules, run simulations, generate proof receipts, constrain AI agents, support credentialing, enable compute-to-data, and operate federated HPC networks without surrendering sovereignty to platforms, vendors, or opaque systems. The Compute Layer is where policy logic meets controlled execution. It is where data becomes computation under governance. It is where AI becomes bounded by clauses. It is where simulations become evidence. It is where credentials become proof-linked. It is where sovereign compute becomes interoperable. It is where the Nexus Sovereignty Framework turns trust into verifiable infrastructure. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/ii.-architecture/compute-layer.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.