> 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/selective-disclosure-and-zk-anchoring.md). # Selective Disclosure and ZK Anchoring ## CAC Privacy Framework in the Nexus Sovereignty Framework: Selective Disclosure, ZK Anchoring, Credential-Gated Access, Encrypted Execution Receipts, Redaction Trails, and Privacy-Preserving Auditability ### Why Privacy Is Foundational to Verifiable Governance Privacy is foundational to verifiable governance because the data required to govern risk is often the same data that can harm people, communities, institutions, markets, and states if exposed without control. Public health systems may require individual or small-area health signals. Disaster response logistics may reveal the location of vulnerable populations, emergency routes, supply depots, shelters, or critical infrastructure. Supply-chain traceability may include commercially sensitive supplier relationships, facility records, cargo movements, and inspection results. Financial aid, finance-readiness, insurance-readiness, and Project SPV evidence workflows may involve personal eligibility data, bankable project evidence, asset telemetry, contractual records, market-sensitive forecasts, and confidential diligence. Security and migration management may involve identity, movement, risk classification, humanitarian protection, and sensitive jurisdictional records. AI governance may involve prompts, retrieval sources, model outputs, tool permissions, agent memory, and incident traces. A governance framework that makes everything visible is not trustworthy. It can become surveillance infrastructure. It can expose people. It can reveal protected communities. It can move market-sensitive information. It can compromise public safety. It can weaken sovereign control. It can chill participation. It can make public-good infrastructure unusable for the very actors it is meant to support. At the same time, a governance framework that hides everything is also not trustworthy. It becomes unverifiable. It prevents dispute review. It allows arbitrary credential actions. It makes public-safe outputs impossible to audit. It prevents cross-jurisdictional recognition. It weakens accountability. It turns evidence into assertion. The Nexus Sovereignty Framework resolves this tension through a **CAC Privacy Framework** based on selective disclosure, zero-knowledge anchoring, encrypted CAC payloads, credential-gated access, redaction trails, audit retention commitments, and governed disclosure profiles. The objective is not radical openness. The objective is **verifiable privacy**: the ability to prove that governance execution occurred correctly, under declared rules, without exposing more data than the context authorizes. The core doctrine is: **Transparency in NSF means verifiable process, not uncontrolled exposure. Privacy means governed minimization, not unaccountable secrecy. Auditability is preserved through commitments, proofs, credentials, access logs, and correction paths.** ### Privacy as a Sovereignty Function Privacy in NSF is not merely personal data protection. It is a sovereignty function. It protects individual rights, community control, institutional confidentiality, national security, public safety, commercial confidentiality, and lawful jurisdictional boundaries. It also preserves the legitimacy of cross-border governance by ensuring that data does not move simply because a clause or agent can technically access it. A CAC may contain or reference sensitive material at many levels: input commitments, credential metadata, simulation outputs, trigger events, geospatial references, jurisdictional scope, node identity, failure states, tenant identity, public-safe labels, Project SPV evidence, AI agent actions, and runtime proof. Even metadata can be sensitive. A timestamped CAC linked to a health clause can reveal outbreak signals. A CAC linked to an insurance-readiness workflow can reveal asset exposure. A CAC linked to a security clause can reveal operational activity. A rollup root may reveal event volume. A credential status update may reveal a person’s role or restriction. Therefore, CAC privacy cannot be an afterthought. It must be part of clause design, input binding, runtime execution, CAC schema, credential evidence, audit indexing, rollup generation, public anchoring, agent access, and dispute resolution. NSF privacy is built into the protocol, not added as a disclosure policy after execution. ### Core Privacy Constructs in CACs CACs support multiple privacy constructs because different governance contexts require different protections. Field-level classification identifies each CAC field as public, restricted, confidential, sovereign-controlled, community-controlled, personal, market-sensitive, security-sensitive, public-safe summary, audit-only, or zero-knowledge commitment. Classification determines storage, encryption, disclosure, and query behavior. Selective disclosure allows some fields of a CAC to be revealed to some actors while other fields remain redacted, encrypted, committed, or accessible only under controlled conditions. A public dashboard may see a status and boundary label. A national authority may see underlying evidence. A community steward may control protected location data. A Project SPV reviewer may see confidential evidence room references. A public user may see only a rollup commitment. Zero-knowledge proofs allow a CAC or CAC-linked credential to prove that a condition was satisfied without revealing the underlying data. A verifier can confirm that a threshold was met, a credential was active, a subject was eligible, or a CAC belongs to a rollup without seeing raw inputs. Encrypted CAC payloads allow sensitive fields to be stored or transmitted while readable only by authorized recipients. Encryption can be field-specific, recipient-specific, jurisdiction-specific, role-specific, time-bound, or emergency-controlled. Credential-gated access uses Verifiable Credentials to determine who may decrypt, view, query, replay, or export CAC fields. Access is based on role, jurisdiction, credential status, purpose, clause trust class, and governance scope. Commitment anchoring allows CAC hashes, Merkle roots, proof commitments, and state commitments to be anchored in audit systems or public ledgers without revealing payload content. Redaction trails record what was redacted, why, by whom or under which policy, what commitment preserves the hidden content, who may override, and how disputes are handled. Privacy profiles define how an entire CAC, clause, rollup, or credential evidence object handles disclosure. Examples include public CAC, restricted CAC, sealed CAC, ZK-proven CAC, community-controlled CAC, sovereign-only CAC, enterprise evidence-room CAC, and public-safe summary CAC. These constructs allow NSF to preserve accountability without turning governance into exposure. ### Selective Disclosure Model Selective disclosure allows CACs to show different information to different authorized actors. It is essential because the same CAC may be relevant to public users, credential issuers, national nodes, regional consortia, community stewards, enterprise evidence rooms, public-safe reviewers, auditors, AI agents, and dispute bodies. A simplified disclosure structure may look like: ```json { "fields": { "trigger": { "type": "sensor", "value": "[REDACTED]", "disclosure_policy": "RevealTo:PublicHealthAdminVC" }, "outputs": { "status": "REVIEW_REQUIRED", "disclosure_policy": "PublicSafeSummary" } } } ``` A mature NSF model should include role, jurisdiction, purpose, credential, time, audit logging, and public-safe conditions: ```json { "disclosure_profile": { "profile_id": "CACDisclosureProfile::PublicHealthRestricted@1.0", "default": "commitment-only", "fields": { "input.health_signal": { "classification": "personal-or-small-area-sensitive", "public": "hidden", "credential_gated": [ { "required_credential": "PublicHealthResponseAuthorityVC", "jurisdiction": "matched-to-cac", "purpose": "response-review", "access": "decrypt" } ], "audit": "access-required" }, "output.public_summary": { "classification": "public-safe", "public": "visible", "required_labels": [ "forecast-based", "not-official-public-warning-unless-authorized" ] }, "attestation.runtime_hash": { "classification": "verification-metadata", "public": "visible" } } } } ``` Disclosure rules may be defined per clause, clause family, jurisdiction, credential schema, data class, tenant, public-safe profile, or governance body. They must be signed and registry-linked. They should be enforced at execution time, not merely at publication time. A CAC should be created with disclosure metadata attached so that downstream systems know what may be revealed. Agents should see only what they are authorized to see. Authorization should be based on role, jurisdiction, credential, issuer status, clause trust class, purpose, data classification, and public-safe constraints. An AI agent should not gain access to raw CAC inputs simply because it can query an audit system. It must present the right credentials, operate under the right policy, and leave an access audit record. Selective disclosure is the mechanism by which NSF supports transparency without overexposure. ### Disclosure Policies as Governed Clause Metadata Disclosure rules should be part of clause governance. A clause that handles sensitive data must declare what fields can be public, restricted, encrypted, zero-knowledge, audit-only, community-controlled, or sovereign-only. It must declare who can access what, under which conditions, and what must be logged. A disclosure policy should include data classification, authorized roles, required credentials, jurisdictional constraints, purpose restrictions, retention period, redaction rules, emergency access, dispute access, public-safe labels, audit logging, and revocation rules. For example, a disaster logistics CAC may expose a public-safe status but hide precise shelter inventory and route details. A public health CAC may expose aggregate risk level but hide individual records. A finance-readiness CAC may expose evidence completeness class but hide underlying commercial records. An insurance-readiness CAC may expose monitoring status but hide exposure data. A community data CAC may expose a protected-knowledge review status but hide underlying local knowledge. Disclosure policies should be tested like other clause logic. Public-safe tests should ensure that prohibited fields cannot appear in public outputs. Credential-gated tests should ensure unauthorized credentials fail. Emergency override tests should ensure access is time-limited and recorded. Privacy must be executable. ### Zero-Knowledge Anchoring of Clause Execution Zero-knowledge anchoring allows CACs to be verified without exposing raw data. For fully private or highly sensitive clauses, the clause logic or selected parts of the clause may be compiled into a ZK circuit. Inputs are committed. The prover generates a proof that the clause executed correctly over committed inputs and produced the declared output. Verifiers can check the proof without seeing hidden inputs. A ZK-anchored CAC may prove: The registered clause hash was used. The input commitments were included. A required credential was valid. A threshold was exceeded. A public-safe aggregation minimum was met. A simulation output fell within an allowed range. A CAC belongs to a rollup. A credential lifecycle update followed the schema. A Project SPV evidence package satisfied completeness rules. A subject met eligibility criteria without revealing personal details. A conceptual ZK proof object may look like: ```json { "zk_anchor": { "circuit": "DisasterReadinessEvidenceTrigger@3.0", "proof_type": "STARK", "verification_key": "did:nsf:zk-registry:2025-Q2", "commitments": { "input_hash": "0xabc123", "clause_hash": "0xdef456", "output_hash": "0x987aaa" }, "public_claims": { "threshold_condition_satisfied": true, "jurisdiction": "commitment-only", "authority_class": "evidence-support" } } } ``` ZK anchoring is powerful, but proof scope must be clear. A ZK proof proves the statement encoded in the circuit. It does not prove that the input data was true, that the model was correct, that a public authority approved the output, that finance is approved, that insurance is underwritten, or that legal compliance has been certified. If the circuit omits a safeguard, the proof does not prove the safeguard. If the input source was compromised before commitment, ZK does not fix source integrity. ZK anchoring protects privacy while preserving verifiability, but it must never become proof-washing. ### Encrypted CAC Payloads and Decryption Policies CACs may contain encrypted fields. Sensitive inputs, personal credentials, geospatial traces, market-sensitive forecasts, institutional evidence, model outputs, public health signals, security records, or Project SPV materials should be encrypted when stored or transmitted outside their original protected environment. Encryption can operate at multiple levels: full-CAC encryption, field-level encryption, attachment encryption, input reference encryption, output encryption, credential evidence encryption, and rollup payload encryption. Public metadata and commitments may remain visible while protected fields remain sealed. Decryption policies should be credential-based and purpose-bound. A field may be decryptable only by holders of a specific credential, in a specific jurisdiction, for a specific purpose, during a specific period, with access logging. A public health emergency reviewer may access health inputs. A community steward may access protected local evidence. A Project SPV reviewer may access enterprise evidence. A national node may access domestic SDZ data. A public user may see only commitments. Encryption schemes may include AES-GCM for symmetric encryption, ECIES or similar public-key encryption for recipient-keyed access, hybrid encryption for performance, threshold encryption for multi-party access, proxy re-encryption for credential-scoped redistribution, and post-quantum-compatible schemes as standards mature. Key choice should be governed by data class and threat model. Encryption must include key lifecycle management: key generation, rotation, revocation, recovery, expiry, escrow where lawful, emergency access, audit, and destruction. Keys should not be controlled by one unaccountable administrator. High-risk contexts may require threshold decryption or dual control. Encrypted CACs allow evidence to be preserved without indiscriminate exposure. ### Privacy-Tiered CAC Classification Each CAC should carry a privacy profile. The profile determines storage, disclosure, proof, access, anchoring, replay, and public-safe treatment. A public CAC may expose most fields because it contains no sensitive data, such as public test results, public reference clauses, or open registry events. A public-safe summary CAC exposes only a safe summary, boundary labels, uncertainty, and commitments. Raw inputs remain hidden. A restricted CAC is visible only to credentialed institutional actors. A sovereign-controlled CAC is held inside a national SDZ or national registry, with external commitments only. A community-controlled CAC is governed by community or Indigenous data rules, with protected knowledge restrictions. A sealed CAC contains encrypted payloads accessible only under credentialed decryption policy. A ZK-proven CAC exposes proof statements and commitments, but not raw data. A controlled-room CAC is accessible only through governed review environments. An enterprise evidence-room CAC is restricted to authorized Project SPV or implementation evidence workflows. An emergency-limited CAC allows temporary expanded access under signed emergency governance, with expiration and after-action review. A profile declaration may look like: ```json { "privacy_profile": "ZK-Proven + Credential-Gated Output", "payload_class": "restricted", "public_anchor": "root-hash-only", "replay_class": "proof-replay", "decryption_policy": "PublicHealthResponseAuthorityVC + jurisdiction-match", "redaction_trail": "required" } ``` Privacy profiles should be registry-defined and conformance-tested. They should not be improvised per output. ### Credential-Linked Decryption Credential-linked decryption ensures that only actors with the right verifiable credentials can access sealed CAC components. The access decision may depend on credential type, issuer, status, jurisdiction, purpose, risk class, public-safe role, and time window. An access control rule may look like: ```json { "access_control": { "required_credential": "DisasterOpsCommanderVC", "jurisdiction": "FRA", "purpose": "emergency-logistics-review", "action": "Decrypt CAC payload", "audit_access": true, "expires_after": "PT12H" } } ``` A mature access policy should also check credential issuer status, revocation state, subject role, delegation rights, emergency authorization if used, and conflict-of-interest flags where relevant. Access should be logged in the Audit Layer. If the credential is revoked, future access should fail. If access was granted under emergency override, expiration and after-action review should occur. Credential-linked decryption enables redacted but actionable CAC streams. A public-safe feed may show that a disaster logistics CAC exists. A credentialed commander can decrypt relevant route or inventory fields. A national node can inspect jurisdictional details. A public user sees only safe status. This is critical for agent autonomy. An AI agent may be allowed to decrypt only fields required for its task, not the full CAC. It may receive a ZK proof that a condition is satisfied rather than the raw evidence. It may be blocked if its credential scope is too broad, stale, or mismatched. Credential-linked decryption turns access into a governed act. ### Public Ledger Anchoring Without Disclosure CACs and CAC Rollups may be anchored to public ledgers without exposing sensitive content. Anchoring can provide external timestamping, tamper evidence, inclusion proof, and long-term resilience. But public ledger anchoring must be minimal. A public anchor should generally include only a hash, Merkle root, state commitment, schema reference, timestamp, and perhaps public-safe metadata. It should not include raw inputs, personal data, protected locations, credential payloads, sensitive clause logic, market-sensitive simulation results, agent identity, community-protected knowledge, or confidential Project SPV evidence. A ledger anchor proves that a commitment existed at or before a time and can be checked if authorized data or inclusion proof is later provided. It does not prove the hidden data is true. It does not prove official endorsement. It does not make the CAC public. It does not override privacy. The seed says the ledger proves “something verifiable happened, and you can check inclusion if authorized.” That is a good formulation. More precisely: A public anchor proves that a cryptographic commitment to a CAC, rollup, or state existed at a recorded time. Authorized parties can verify inclusion and inspect permitted fields according to disclosure policy. Public ledger anchoring should be optional and policy-driven. Some sovereign, community, security, health, or enterprise contexts may prohibit public anchoring or allow only delayed anchoring. Others may require sovereign ledger anchoring instead of public blockchain anchoring. Anchoring supports integrity without exposure. ### Redaction Trails and Forensic Recovery Redaction must not become a tool for erasing accountability. Every material redaction should leave a trail. The trail should state what field was redacted, why it was redacted, under which policy, by which actor or automated policy, what commitment preserves the hidden content, who may access it, what audit retention hash exists, and what override or dispute path applies. A redaction record may include a `RedactionReasonRecord`, `AuditRetentionHash`, disclosure policy, signer, timestamp, field path, classification, and review status. It may be represented as a VC-like record, but should avoid implying legal certification unless issued by an authorized body. A redaction reason may include personal data protection, community-protected knowledge, security-sensitive data, public-safe map restriction, market-sensitive forecast, sovereign restriction, controlled-room evidence, child or vulnerable population protection, confidential Project SPV evidence, active incident response, or legal privilege where applicable. Forensic recovery should be possible under governed conditions. A dispute body, credential issuer, public authority where lawful, community steward, emergency governance process, controlled-room reviewer, or court may receive access depending on policy and law. Emergency access must be time-limited, logged, and reviewed. Treaty-mandated disclosure review should occur only where an authorized treaty process exists. Redaction should not destroy auditability. It should shift verification from open visibility to governed access. ### Privacy, Auditability, and the Difference Between Visibility and Accountability NSF must make a fundamental distinction: visibility is not the same as accountability. A system can expose everything and still be unaccountable if records are not structured, proofs are weak, and authority is unclear. A system can hide raw data and still be accountable if commitments, proofs, audit trails, credentialed access, and correction paths are strong. Privacy-preserving auditability relies on several mechanisms: hash commitments, Merkle inclusion proofs, ZK proofs, encrypted payloads, access logs, credential-gated disclosure, controlled-room replay, public-safe summaries, redaction trails, and audit retention records. Together, these allow auditors and authorized reviewers to verify process without unnecessary exposure. This is particularly important for public-good governance. Public trust does not require public exposure of every sensitive record. It requires confidence that records exist, that rules governed them, that access is controlled, that disputes can be reviewed, that corrections are possible, and that public claims are bounded. NSF’s guarantee should be auditability, not universal visibility. ### Privacy for CAC Rollups CAC Rollups require privacy controls because aggregation can reveal patterns. A rollup may reveal the number of executions in a location, the existence of a public health event, the volume of credential suspensions, the timing of a market-sensitive forecast, or the intensity of a disaster response. Privacy-preserving rollups may publish only root hashes. They may use ZK proofs for aggregate claims. They may suppress small counts. They may delay publication. They may use jurisdictional mirrors. They may provide different views for public, national, regional, community, and enterprise actors. They may use differential privacy for aggregate statistics where appropriate. A rollup privacy profile should define which metadata is public, whether counts are public, whether time windows are coarse-grained, whether jurisdiction is exact or masked, whether inclusion proofs require authorization, and whether public anchors are allowed. Rollup privacy prevents aggregate transparency from becoming indirect disclosure. ### Privacy for AI Agents and Copilots AI agents pose special privacy risks because they can retrieve, summarize, combine, infer, and disclose information. An agent that has access to CACs may accidentally reveal hidden fields, infer sensitive patterns from metadata, combine public and restricted data, or use memory inappropriately. NSF agents must operate under privacy-aware access controls. They should receive only the fields required for the task. They should verify disclosure policy before summarizing. They should not store restricted CAC content in long-term memory unless policy permits. They should not infer protected attributes or disclose sensitive geospatial details. They should not reveal confidential Project SPV evidence, market-sensitive forecasts, or community-protected knowledge. They should respect public-safe labels. Agent outputs should be checked against public-safe rules. If an agent generates a public summary from restricted CACs, the summary should be validated before release. Agent access to CACs should itself be logged. Agent credentials should determine field access. Privacy-preserving agent design is essential because AI can turn selective access into uncontrolled synthesis if not governed. ### Privacy for Project SPVs, Finance-Readiness, and Insurance-Readiness Project SPV and capital-relevant workflows require strong privacy. Evidence packages may include engineering data, asset telemetry, financial models, contracts, climate risk simulations, maintenance logs, safeguard records, stakeholder records, insurance exposure data, and investor-sensitive materials. These should not become public because a CAC was generated. CACs can support confidential diligence by exposing proof of evidence checks, completeness, model linkage, and controlled-room review without exposing raw evidence. A finance-readiness CAC may show that required evidence exists and was reviewed under a proof profile. It must not disclose confidential financial records publicly. It must not imply finance approval, investment advice, credit rating, or guarantee. An insurance-readiness CAC may show that exposure data was bound, hazard models were linked, and monitoring evidence exists. It must not expose sensitive asset details publicly. It must not imply underwriting, coverage, claim approval, pricing, or insurability. Privacy is what makes proof-based capital-relevant evidence usable without regulated overclaim or commercial exposure. ### Privacy Across GNC, RNC, and NNC Architecture Privacy controls operate across the Nexus multiscale architecture. At the national level, National Nexus Consortiums may enforce domestic SDZ privacy, national data protection rules, public authority access, and national registry disclosure policies. National CACs may publish only commitments externally. At the regional level, Regional Nexus Consortiums may coordinate cross-border rollups, shared simulations, and public-safe summaries while preserving national raw data control. Regional systems should use commitments, ZK proofs, and selective disclosure to avoid centralizing sovereign data. At the global level, the Global Nexus Consortium may define privacy profiles, CAC disclosure schemas, ZK proof formats, public-safe vocabularies, redaction trail standards, and interoperability rules. It should not centralize sensitive CAC payloads. At the community level, community and Indigenous governance bodies may define protected knowledge rules, local disclosure limits, community-controlled decryption, public-safe map masking, and grievance-based access. Community privacy is not just personal privacy; it includes collective rights and knowledge stewardship. At the enterprise layer, National Consortium Companies, Project SPVs, operators, providers, insurers, investors, and contractors may maintain controlled evidence-room CACs under enterprise confidentiality. These remain scoped and do not imply public-good endorsement or regulated approval. This multiscale privacy architecture enables interoperability without extraction. ### CAC Privacy Boundary Statement The CAC Privacy Framework supports selective disclosure, zero-knowledge anchoring, encrypted payloads, credential-gated decryption, public ledger commitments, redaction trails, privacy-tiered CAC profiles, privacy-preserving rollups, agent-safe access, Project SPV evidence confidentiality, finance-readiness evidence, insurance-readiness evidence, and public-safe auditability. It does not by itself create legal privilege, regulatory compliance, public authority approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty compliance, or immunity from lawful disclosure. Privacy controls protect and govern access to execution records under defined policies. Their legal effect depends on applicable law, competent authorities, contracts, data protection regimes, privilege rules, community governance, and jurisdictional process. A redaction is not deletion. A hash anchor is not disclosure. A ZK proof is not data truth beyond the statement proven. Credential-gated access is not universal authority. Emergency decryption is not unlimited access. A public-safe summary is not official public warning unless competent authority provides that status. A finance-readiness privacy profile is not finance approval. An insurance-readiness privacy profile is not underwriting. This boundary must appear in CAC schemas, disclosure policies, registries, verifier tools, public-safe outputs, wallets, agent policies, and audit dashboards. ### Privacy in NSF as a Pillar of Trust In NSF, transparency and privacy are not opposites. They are co-designed. Trust is not derived from exposing everything. Trust is derived from verifiable process, accountable access, proof-scoped disclosure, and correctionable records. Privacy protects people from governance overreach. It protects communities from extraction. It protects institutions from reckless disclosure. It protects markets from unnecessary shock. It protects public safety. It protects sovereignty. It protects participation. It protects the legitimacy of the system itself. But privacy must not become a shield for unaccountable power. Every redaction must leave a commitment. Every encrypted payload must have a policy. Every access must be logged. Every ZK proof must define its statement. Every public anchor must be minimal. Every emergency override must be bounded. Every dispute must have a recovery path. Every agent must be access-controlled. Every public-safe output must be checked. The NSF privacy principle is simple: **Auditability, not exposure, is the guarantee.** Selective disclosure, ZK proofs, encrypted CACs, credential-gated access, redaction trails, and public-safe commitments allow governance to scale without turning risk infrastructure into surveillance infrastructure. Privacy is not a privilege in NSF. It is a constitutional layer of the trust protocol. That is the role of the CAC Privacy Framework in the Nexus Sovereignty Framework: to make governance execution verifiable without making sensitive life, institutional, community, sovereign, or market data unnecessarily visible. --- # 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/selective-disclosure-and-zk-anchoring.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.