> 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/iv.-verifiable-execution/proof-of-execution.md).

# Proof-of-Execution

## Proof-of-Execution in the Nexus Sovereignty Framework: Verifiable Runtime Evidence, Enclave and ZK Attestation, Multi-Party Verification, Execution Anchoring, and Institutional Memory for Clause-Attested Compute

### The Role of Proof-of-Execution in NSF

Proof-of-Execution (PoE) is the mechanism by which the Nexus Sovereignty Framework verifies that a Smart Clause did not merely produce an output, but executed under the correct runtime, proof, governance, and jurisdictional conditions. It is the execution-integrity layer inside Clause-Attested Compute. A CAC records the execution receipt. PoE is the proof component that supports the claim that the clause actually ran as declared, in the approved environment, with the committed inputs, under the registered clause hash, and without unauthorized runtime alteration.

In ordinary digital systems, execution is often trusted because the platform says it happened. Logs are accepted because the server wrote them. API outputs are accepted because the application returned them. Audit trails are reconstructed from databases, administrator records, timestamps, and platform monitoring. For high-stakes governance, this is not enough. A governance-critical execution may affect disaster readiness, public-safe reporting, credential status, AI agent permissions, controlled evidence rooms, climate-risk records, emissions evidence, Project SPV diligence, finance-readiness evidence, insurance-readiness evidence, or cross-border coordination. The system must be able to prove not only what output appeared, but how that output was produced.

PoE provides that proof. It attests that a specific clause package executed under a specific runtime measurement, with a specific input commitment, under a specific proof profile, in a specific jurisdictional and governance context. It allows downstream systems to verify execution origin, runtime configuration, enclave or proof validity, determinism profile, input-output binding, and audit anchoring.

This is especially important where actors do not fully trust one another. A national node may not want to trust a regional operator’s server. A credential issuer may not want to trust an AI agent’s assertion. A Project SPV reviewer may not want to trust a vendor dashboard. A public-safe reviewer may not want to trust a black-box model run. A community steward may require proof that protected data was processed only inside an authorized environment. A cross-border consortium may need evidence that each participating node ran the same clause under compatible conditions. PoE creates a shared verification language across these trust boundaries.

However, PoE must be boundary-safe. It proves execution integrity under a defined proof profile. It does not prove that the clause was legally binding, that the input data was true, that the model was correct, that a public authority endorsed the output, that finance is approved, that insurance is underwritten, or that regulatory compliance has been certified. It proves that a governed computation ran as declared. The meaning of that computation remains tied to governance scope, data provenance, credential authority, simulation validity, public-safe rules, and applicable law.

The core doctrine is:

**Proof-of-Execution proves that a registered clause execution occurred under a verifiable runtime and proof profile. It is evidence of execution integrity, not a substitute for legal authority, institutional judgment, data truth, model validity, public approval, finance approval, or insurance underwriting.**

### PoE as the Inner Proof Layer of CAC

PoE and CAC are closely related but not identical. A CAC is the full execution receipt. It includes clause identity, input provenance, parameters, credentials, simulation references, trigger metadata, output, governance scope, hash graph, audit anchor, and disclosure profile. PoE is the execution proof embedded inside the CAC. It focuses on runtime and computation integrity.

A CAC without PoE may still be a useful audit record, but it is weaker. It may show that a system claims an execution occurred, but not prove that the registered clause ran in an approved environment. A CAC with PoE gives stronger assurance: the computation was performed inside a measured enclave, verified circuit, controlled runtime, multi-party execution agreement, or other registered verifiable compute backend.

PoE therefore answers the question: **can the execution claim be independently verified?**

The PoE layer should include runtime measurement, proof type, attestation evidence, prover identity, verifier identity or verifier set, execution environment hash, clause workload hash, input commitment binding, output commitment binding, timestamp, replay protection, jurisdictional scope, and proof verification result.

The CAC wraps this proof into institutional context. The PoE says: this computation ran. The CAC says: this computation ran as part of this governed clause execution, under this scope, producing this output, with this audit record and these boundaries.

This distinction allows NSF to support multiple proof backends while preserving one execution receipt format.

### NSF-Defined Properties of a Valid Execution Proof

A valid NSF execution proof must demonstrate several properties.

First, it must demonstrate clause identity. The proof must bind to the registered Clause ID, Clause Hash, dependency graph, compiler or interpreter version, and runtime package. A proof that an unknown program ran is not a valid Smart Clause PoE.

Second, it must demonstrate runtime integrity. The proof must show that execution occurred inside an approved runtime profile, such as a TEE, ZK circuit, deterministic reference runtime, controlled-room runtime, sovereign node runtime, edge runtime, or hybrid proof environment. The runtime measurement must match registry-recognized values.

Third, it must demonstrate input commitment. The proof must bind to the input hashes, commitments, encrypted input references, ZK commitments, or controlled-room references used during execution. It must prevent later substitution of inputs.

Fourth, it must demonstrate output binding. The output recorded in the CAC must be bound to the execution proof. A valid PoE should not allow an output to be swapped after execution.

Fifth, it must demonstrate isolation or proof-correctness. In a TEE, this means the workload ran in a measured protected environment under attestation. In ZK, this means the proof verifies that the computation followed the registered circuit. In multi-party execution, this means the required validator set agreed on output under the declared protocol.

Sixth, it must demonstrate governance scope. The proof should include or reference jurisdiction, SDZ, node credential, authority class, execution profile, and allowed workload scope. A proof generated in an unauthorized environment should not validate high-consequence execution.

Seventh, it must demonstrate replay protection. It must include execution ID, nonce, timestamp, trigger reference, or equivalent anti-replay element so old proofs cannot be reused to support new outputs.

Eighth, it must demonstrate verifier status. The CAC should record whether the PoE was verified, by whom or what, under which verifier profile, at what time, and with which result.

Ninth, it must demonstrate safe-mode compatibility. If proof verification fails, the system must know how to block, mark disputed, freeze execution, route review, or notify governance.

A valid PoE is therefore not a single signature. It is a structured proof object linked to runtime, clause, inputs, outputs, scope, and governance.

### Execution Backends Supporting PoE

NSF should support multiple execution models for PoE because different workloads require different proof properties.

TEE-backed execution uses hardware-supported isolation and remote attestation. It is suitable for complex workloads, confidential inputs, embedded simulations, AI policy gates, Project SPV evidence rooms, national SDZs, and controlled data processing. It produces PoE through enclave or confidential VM quotes, runtime measurements, node credentials, and output signatures.

ZK-backed execution uses zero-knowledge proof systems such as SNARKs or STARKs to prove that a computation was performed correctly over committed inputs without revealing those inputs. It is suitable for privacy-preserving credential checks, threshold proofs, eligibility proofs, simple deterministic clauses, selective disclosure, and sensitive cross-border verification. It produces PoE through circuit proofs, verification keys, public inputs, and proof commitments.

Deterministic reference execution uses a registered deterministic runtime, canonical input vectors, and replayable outputs. It is suitable for low-sensitivity public clauses, open tests, registry checks, documentation examples, and ordinary conformance verification. It produces weaker PoE than TEE or ZK, but can still be valid where secrecy and isolation are not required.

Multi-party execution uses multiple independent validators, enclaves, sovereign nodes, or verifiers to execute or validate the same clause and agree on output. It is suitable for high-stakes cross-jurisdictional workflows, contested data environments, public-good reference computation, and redundancy against single-node failure. It produces PoE through threshold signatures, output agreement, validator credentials, and audit records.

Hybrid execution combines proof models. A TEE may run a complex simulation while a ZK proof verifies a threshold condition. Multiple TEEs may execute the same clause and aggregate signatures. A controlled-room reviewer may sign a TEE output. A sovereign node may run local execution and publish public hash commitments. Hybrid PoE allows NSF to balance complexity, privacy, sovereignty, and verifiability.

Edge PoE supports constrained environments such as disaster zones, remote sensors, mobile devices, drones, ships, clinics, or industrial gateways. It may rely on secure elements, signed snapshots, local attestation, bounded offline execution, and later synchronization. Edge PoE should have narrower proof scope and stronger safe-mode rules.

Each backend produces a CAC with embedded PoE, including attestation metadata, prover identity, verifier identity or verifier set, runtime configuration, proof profile, and proof verification result.

The architecture should be backend-plural but schema-consistent.

### Enclave-Based Runtime Isolation

In TEE-based execution, clause logic and inputs are loaded into an enclave or confidential compute environment. The protected environment isolates runtime memory, intermediate state, keys, and outputs from ordinary host access, within the limits of the TEE’s threat model. The operating system, hypervisor, cloud operator, or host administrator should not be able to inspect enclave memory or alter execution without detection.

The enclave generates attestation evidence. This evidence includes measurement hash, runtime hash, workload hash, enclave public key or report key, platform security version, configuration, and hardware attestation chain. NSF-specific metadata should bind the attestation to Clause ID, Clause Hash, trigger type, jurisdiction, SDZ, node credential, and execution profile.

The quote or attestation token may be signed by a hardware vendor attestation chain, a platform root, an attestation service, or a registered validator root depending on TEE type. The verifier checks this evidence against registry-recognized measurements, node credentials, revocation lists, platform vulnerability status, and allowed workload scope.

After execution, the enclave seals or signs the output. The CAC includes the output hash, input commitments, attestation quote or quote hash, runtime metadata, node signature, and audit anchor. Sensitive outputs may be encrypted to authorized recipients, while public commitments remain available for verification.

TEE PoE provides confidentiality and integrity for execution. It does not prove the clause is correct, the inputs are true, or the result has legal authority. It proves that the registered workload ran in a measured protected environment and produced the recorded output.

### ZK Proof-of-Execution

For privacy-critical or cross-boundary verification, NSF supports ZK-based Proof-of-Execution. In ZK execution, clause logic is compiled, transpiled, or represented as a circuit or proof system. Inputs are committed. The prover executes the clause logic inside the proof system and generates both output and proof. A verifier checks the proof using public verification material without learning private inputs beyond permitted public outputs.

ZK PoE can demonstrate that the clause logic matched a registered circuit hash, the committed inputs satisfied declared constraints, and the public output follows from the clause logic. It is especially useful where raw data cannot be revealed across jurisdictions, where credential attributes must remain private, where eligibility needs proof without disclosure, or where sensitive thresholds must be verified without exposing protected data.

For example, a ZK CAC may prove that a holder has an active credential issued by a recognized issuer, is not revoked, and satisfies a jurisdictional condition, without revealing the holder’s full identity. A ZK threshold proof may show that a risk score exceeded a governed threshold without revealing all underlying project data. A ZK public-safe proof may show that aggregation minimums were met without exposing individual records.

ZK PoE requires careful proof scope. A circuit proves only what it is designed to prove. If the circuit omits a public-safe condition, the proof does not establish that condition. If the circuit uses committed inputs that were themselves false, the proof does not make them true. If the clause logic was simplified for circuit feasibility, the CAC must state that. If a model is too complex for ZK, only specific output checks may be proven.

ZK PoE should include circuit ID, circuit hash, clause hash, proving key commitment, verification key, public inputs, proof commitment, output commitment, prover identity where applicable, verifier status, and proof timestamp.

ZK execution is powerful because it allows verification without exposure. It is safe only when proof scope is explicit.

### Runtime Metadata in CAC

Each CAC should include a `runtime_info` or equivalent section that records the execution backend and proof details. The seed example is useful, but should be generalized to support multiple backends and claims-safe validator language.

A TEE-backed runtime record may look like:

```json
"runtime_info": {
  "type": "TEE",
  "platform_profile": "Intel-SGX-compatible",
  "runtime_profile": "NSF-WASM-ConfidentialRuntime@1.0",
  "build_hash": "0xabc123",
  "enclave_id": "0xdeadbeef",
  "workload_hash": "0x...",
  "clause_hash": "0x...",
  "prover_did": "did:nsf:tee-node:5",
  "prover_credential": "TEEExecutorVC@1.0",
  "attestation_signature": "0xCAFEBABE",
  "verified_by": "NSFVerifierSet@2025-Q2",
  "verification_status": "VERIFIED",
  "proof_profile": "TEE-PoE@1.0"
}
```

A ZK-backed runtime record may look like:

```json
"runtime_info": {
  "type": "ZK",
  "proof_system": "STARK",
  "circuit_id": "SCLThresholdCircuit@2.1",
  "circuit_hash": "0x...",
  "verification_key_hash": "0x...",
  "proof_hash": "0x...",
  "public_inputs_hash": "0x...",
  "prover_did": "did:nsf:zk-prover:12",
  "verified_by": "ZKVerifierProfile@2025-Q2",
  "verification_status": "VERIFIED",
  "proof_profile": "ZK-PoE@2.1"
}
```

This metadata allows downstream systems to verify execution origin, trace runtime compliance, perform audits, validate trust domain membership, and determine replay class. It also allows governance bodies to identify affected executions if a runtime, circuit, node, or proof profile is later deprecated or compromised.

The field `verified_by` should identify a verifier set, validator quorum, national node, controlled-room verifier, or automated verification service. It should not imply legal audit or certification unless that is actually performed by an authorized actor.

### Isolation from Host and External Interference

A valid PoE must address host interference. For TEE execution, NSF should require that the host cannot directly access enclave memory, clause state, protected inputs, intermediate results, or enclave signing keys. All input and output must pass through mediated, signed, audit-traced channels. Network access should be blocked unless declared. File access should be restricted. System calls should be sandboxed. Time and randomness should be mediated. Cryptographic keys used inside the enclave should be hardware-bound or enclave-bound where appropriate.

However, the system must be honest about limitations. Hosts may still deny service, delay messages, reorder inputs, starve resources, manipulate unprotected I/O, or exploit side channels if mitigations are insufficient. TEE PoE reduces interference risk but does not eliminate all host power. For high-consequence use, NSF may require redundant execution, multi-TEE agreement, ZK checks, sensor quorum, controlled-room review, or jurisdictional validator confirmation.

Side-channel protections should be part of runtime profile. Microcode status, vulnerability patches, enclave configuration, memory access patterns, constant-time operations where relevant, and workload risk classification should be recorded. If a platform vulnerability affects a TEE class, affected nodes and CACs should be flagged.

For ZK execution, host interference is addressed differently. The verifier checks the proof. The host can attempt denial-of-service or provide wrong inputs, but cannot forge a valid proof for a false computation under sound assumptions. However, if the circuit is wrong or inputs are false, the proof can still verify. ZK protects computation correctness under the circuit, not source truth.

PoE must therefore combine isolation with input binding, output binding, audit, and safe-mode logic.

### Execution Proof Anchor Points

PoE records should be anchored so they become tamper-evident and discoverable. The primary anchor is the Audit Layer. Every PoE should have an audit record with timestamp, execution ID, proof hash, CAC hash, clause hash, runtime hash, verifier status, and storage location.

Optional public anchoring may be used for non-sensitive commitments. A hash of the CAC, PoE, or audit root may be anchored to public blockchains, content-addressed storage, or external timestamping systems. Public chains such as Ethereum-like systems, Bitcoin-style timestamping, Filecoin-like storage, or Arweave-like archives may provide external timestamp evidence. But sensitive payloads, personal data, protected geospatial data, critical infrastructure information, community knowledge, or Project SPV confidential evidence should not be placed on public immutable infrastructure.

Treaty-specific append-only logs may be used only where authorized by treaty bodies or competent institutions. NSF should not imply that it operates official treaty enforcement logs unless that status exists. Safer language is **treaty-aligned evidence logs**, **framework-referenced audit logs**, or **authorized treaty-specific logs where adopted by competent bodies**.

Domain-specific registries may reference PoE records. But examples such as ICAO, WHO, FATF, or other institutions should be framed as **referenced mappings**, **authorized integrations where approved**, or **domain-specific registries** unless official adoption exists. NSF should not imply that these bodies verify PoE by default.

PoEs may be verifiable by public auditors where public-safe, by governance reviewers, credential issuers, national nodes, cross-jurisdictional verification services, controlled-room reviewers, or authorized enterprise actors depending on disclosure profile.

Anchoring makes execution evidence durable. It does not make it legally authoritative by itself.

### Multi-Party Verification

Some clause executions should require more than one proof source. High-stakes or cross-jurisdictional contexts may require multi-party verification.

Multi-TEE execution agreement can run the same clause across multiple independent TEE nodes and compare outputs. If three of five nodes agree, a threshold signature may validate the output. This reduces dependence on one node, one hardware vendor, one operator, or one jurisdiction.

Delegated verifier attestation can allow authorized verifiers to validate PoE on behalf of users, public-safe dashboards, credential issuers, or national nodes. Delegation must be scoped and audit-recorded.

Layered PoE validation across sovereign nodes can allow national nodes to verify their own data locally while sharing proof commitments regionally. A regional consortium can validate that national executions occurred without receiving raw national data.

ZK plus TEE hybrid proofs can combine confidential execution with privacy-preserving verification. The TEE handles complex computation; ZK proves selected claims about outputs. Or ZK proves credential eligibility; TEE handles protected data processing.

Jurisdictionally constrained validation sets can require that certain executions be verified only by approved validators inside a jurisdiction or SDZ. Fork-specific verifier scopes can require that a national fork be verified by national validators, while a global reference clause may be verified by public reference validators.

Multi-party verification should be composable. A CAC may include multiple proof components, each with its own verifier, scope, and status. The CAC should distinguish required proofs from optional proofs. If a required proof is missing, execution should be invalid or limited.

Multi-party PoE increases resilience and legitimacy, but it must remain efficient and proportionate.

### PoE for Reactive Clauses

Reactive Clauses need PoE because they execute in response to external events. A flood trigger, emissions threshold, sensor update, AI agent violation, or credential state change can activate governance logic without direct manual invocation. The system must prove that the trigger was valid and that the clause executed correctly in response.

PoE for Reactive Clauses should bind trigger metadata, trigger source signature, event timestamp, input commitments, recurrence state, cooldown status, parameter values, and clause output. It should prove that the clause ran only after trigger validation. It should also record if the trigger was rejected.

If a trigger leads to public-safe output, credential review, or enterprise workflow, the PoE must support downstream verification. If the trigger is later disputed, the PoE and CAC provide forensic evidence.

Reactive PoE prevents event-triggered governance from becoming unverifiable automation.

### PoE for Embedded Simulations

Embedded simulations require PoE because model calls can influence clause behavior. A dynamic threshold, forecast score, risk classification, model drift output, or scenario result may determine whether a clause triggers review, blocks an action, or generates evidence.

PoE for embedded simulations should bind model ID, model version, simulation bundle, run ID, input commitments, output commitment, runtime proof, uncertainty metadata, and model governance status. If the simulation runs inside a TEE, TEE attestation supports execution integrity. If a ZK proof verifies a threshold statement, the proof should be included. If multiple validators review the simulation, signatures should be recorded.

A simulation PoE does not prove prediction certainty. It proves that the registered model or proof profile produced the recorded output under declared conditions.

PoE makes simulation-dependent governance auditable.

### PoE for Credential and Identity Actions

Credential-triggered actions require strong PoE. If a clause issues, suspends, revokes, recognizes, or routes review for a credential, the system must prove the credential state and clause execution path.

PoE should bind credential schema, credential hash, issuer status, subject commitment, revocation status, recognition status, timestamp, and clause output. If privacy is required, ZK credential proofs may show eligibility without exposing full identity.

High-impact credential changes should require issuer authority and review paths. A PoE can support a credential status update, but it should not imply professional license revocation, public authority action, or legal determination unless the issuer and competent authority provide that effect.

PoE ensures credential actions are evidence-bound.

### PoE for Project SPVs, Finance-Readiness, and Insurance-Readiness

Project SPVs and capital-relevant evidence workflows benefit from PoE because they require trust across many parties while preserving confidentiality. A PoE can show that a clause evaluated asset telemetry, climate scenario evidence, maintenance records, safeguard evidence, or monitoring obligations under a controlled runtime.

Finance-readiness PoE can support evidence completeness, scenario linkage, controlled-room review, and auditability. It must not be framed as finance approval, creditworthiness, investment advice, guarantee, solicitation, or rating.

Insurance-readiness PoE can support exposure evidence, hazard model linkage, parametric trigger evidence, basis risk analysis, or monitoring evidence. It must not be framed as underwriting, coverage, claim approval, pricing, or insurability.

PoE strengthens evidence review, but licensed or authorized actors remain responsible for regulated decisions.

### PoE Verification Lifecycle

PoE verification should be lifecycle-aware. A proof may be valid at one time and later affected by vulnerability disclosure, node revocation, runtime deprecation, circuit bug, model quarantine, or registry correction.

Verification should include current validation and historical validation. Current validation asks whether the proof is acceptable now. Historical validation asks whether the proof was valid under the registry and threat model at execution time. Both matter.

If a TEE vulnerability later affects a class of executions, NSF should identify affected CACs and mark them under review, disputed, or historically accepted with caveat depending on severity. If a ZK circuit bug is discovered, dependent proofs may require re-verification. If a node credential was compromised, executions within the compromise window may require review.

PoE records should therefore include enough metadata to support future reassessment. Proof-of-Execution is not a one-time claim. It is part of institutional memory.

### Runtime Failure and PoE Safe Mode

If PoE cannot be verified, the clause execution should enter safe mode. Failure conditions include invalid attestation quote, runtime measurement mismatch, revoked node credential, expired quote, unsupported proof profile, invalid ZK proof, unknown circuit hash, missing input commitment, output hash mismatch, stale registry snapshot, unauthorized jurisdiction, or signer key compromise.

Safe-mode actions may include rejecting CAC, marking CAC disputed, freezing clause execution on that node, notifying registry stewards, routing to controlled review, requiring replay, suspending node credential, blocking credential effects, or issuing a failure notice.

PoE failure is serious because it undermines execution integrity. The system must not silently accept unverifiable proofs.

### PoE Boundary Statement

Proof-of-Execution supports verifiable runtime evidence, clause execution integrity, isolation claims, input-output binding, runtime attestation, ZK verification, multi-party validation, CAC generation, audit anchoring, replay, dispute review, AI agent governance, Project SPV evidence, finance-readiness evidence, and insurance-readiness evidence.

It does not by itself prove legal compliance, public authority action, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warnings, treaty compliance, legal liability, data truth, model correctness, or policy wisdom. PoE proves that a defined computation executed under a defined proof profile. The meaning and consequence of the output depend on clause authority class, source data, credential scope, simulation validity, governance review, jurisdiction, public-safe rules, and applicable law.

A PoE is not legal authority.

A TEE quote is not certification.

A ZK proof is not truth beyond the statement proven.

A runtime attestation is not model validation.

A disaster-trigger PoE is not an official warning.

A finance-release PoE is not finance approval unless a lawful authorized program gives it that effect.

An emissions PoE is not a penalty determination unless competent authority adopts that process.

A treaty-aligned PoE is not treaty enforcement.

This boundary must appear in CAC schemas, verifier tools, registry records, public-safe outputs, and governance documentation.

### Proof-of-Execution as Institutional Memory

Proof-of-Execution transforms Smart Clause execution from ephemeral computation into verifiable institutional memory. It ensures that execution does not disappear into opaque platforms, vendor dashboards, private databases, or unverifiable AI agents. It gives every material execution a proof trail.

PoE enables post-event dispute resolution because reviewers can inspect how the clause ran.

It enables regulatory and institutional traceability without implying regulatory approval.

It enables simulation validation by linking model-dependent outputs to execution proof.

It enables governance audits at scale because executions become machine-verifiable.

It enables cross-jurisdictional review because proofs can travel without raw data where appropriate.

It enables AI agent accountability because tool decisions can be proof-bound.

It enables Project SPV evidence review without uncontrolled disclosure.

It enables finance-readiness and insurance-readiness evidence without crossing into regulated determinations.

With PoE, governance no longer depends on trust in opaque systems. It becomes a sequence of verifiable, cryptographic, proof-scoped records: clause by clause, input by input, runtime by runtime, output by output, jurisdiction by jurisdiction.

This is not a replacement for law, institutions, or human judgment. It is the execution memory those systems need in order to operate in a world of distributed compute, AI agents, sovereign data, dynamic risk, and cross-border coordination.

That is the role of Proof-of-Execution in the Nexus Sovereignty Framework: to make governance-critical computation externally verifiable, institutionally reviewable, jurisdictionally bounded, and permanently accountable.


---

# 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/iv.-verifiable-execution/proof-of-execution.md?ask=<question>&goal=<endgoal>
```

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

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

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