> 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/introduction/knowledge/x.-knowledge-base-integrity.md).

# X. Knowledge Base Integrity

The integrity commitments of this site: kinds of trust, honest status, claims tied to records, sovereignty wording, accessibility, and how corrections are made.

<details>

<summary>Document record · Draft · Legal review required · Updated 21 October 2026</summary>

|                  |                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Status**       | Draft. Explanatory page; it creates no rights or obligations.                                                                                                                                                                                                                                                                                                                                                                                                 |
| **Legal review** | Required before final publication.                                                                                                                                                                                                                                                                                                                                                                                                                            |
| **Version**      | 2026.10.21-r3                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| **Updated**      | 21 October 2026 · reviewed every 180 days                                                                                                                                                                                                                                                                                                                                                                                                                     |
| **Owner**        | Documentation desk (named reviewer pending)                                                                                                                                                                                                                                                                                                                                                                                                                   |
| **Based on**     | Nexus Documentation Standard (draft); Nexus constitutional directive D-V3-0005; Nexus institutional architecture and participation; Nexus editorial constitution (draft); the Nexus model and the Nexus Consortium model as published on the sites (2026-10-21); the [Nexus Standards](/organization/institutions/nexus-standards.md) governance and [NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) |
| **Corrections**  | Public corrections route to be announced; corrections are published as new dated versions.                                                                                                                                                                                                                                                                                                                                                                    |

</details>

**Where this fits:** all six sectors · all six pillars, above all Nexus Standards and Nexus Reports for the rules of this documentation · the Nexus Consortium, with GCRI Canada as Secretariat · Publish and Renew in the cycle · integrity.

{% hint style="info" %}
**Read with the current model (21 October 2026).** The documentation itself is now organized in two layers: a spine ([The Model](/organization/model.md), [Institutions](/organization/institutions.md), [Programme](/organization/programme.md), [Governance in operation](/organization/governance-in-operation.md), [Finance readiness](/organization/finance-readiness.md), [Use by](/organization/use-by.md), [Systems](/organization/systems.md), [Nexus Standards](/organization/standards.md) and [Reference](/organization/reference.md)), and under it the five doctrine areas this section describes. Citation and identifiers follow NS-2 and NS-1, and drafting follows NS-4 \[9] \[10] \[11]; the house rules are in the [citation style](/organization/reference/citation-style.md). Everything described here is in formation: no national programme is recorded as constituted or active, and the current service level is R0, information and enquiries ([status and service levels](/organization/governance-in-operation/status-and-service-levels.md)) \[12]. Shared infrastructure follows the safeguards the United Nations sets for digital public infrastructure \[13] and the commitments of the Global Digital Compact \[14].
{% endhint %}

{% hint style="info" %}
**Status.** System capabilities described on this page are target architecture under development. Nothing here states that a capability is in production use, certified or offered as a service.
{% endhint %}

## In brief

Knowledge base integrity means that what this site says matches what the records show, in scope, status and authority, and that errors are corrected visibly. It covers more than factual accuracy: consistent terms, honest status per dimension, claims tied to records, boundaries that survive quotation, accessible writing and a recorded correction for every substantive change. Integrity is maintained by the review process in [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md); this page states the commitments that process serves \[1].

## Summary

This page defines the integrity model of the Nexus knowledge base. It explains how trust is built through structural alignment, truthful expression, stable terminology, visible maturity, and correction discipline across the corpus.

It is the key page for readers who need to understand why Nexus treats documentation as part of its governance and public-good architecture.

{% hint style="info" %}
**Nexus Observatory Protocol.** On this site, Nexus Observatory Protocol is the observation protocol owned by [NXS-OPS](/organization/systems/nxs-ops.md), the observatory protocol system, in collaboration with [NXS-EOP](/organization/systems/nxs-eop.md), the Earth observation, geospatial and digital-twin fabric, and [NXS-SIG](/organization/systems/nxs-sig.md), the authorized signal, spectrum and communications integrity system. Together these three systems form the observatory ecosystem.

**Nexus of Observatories.** Every Nexus platform and system includes its own observatory capability, covering remote sensing, in-situ instruments and edge deployments. Across every area where these observatories are implemented, including implementation pilots in programme areas, they form the Nexus of Observatories, which is part of the not-for-profit programme architecture. On this site, "Nexus Observatory" refers only to this observatory capability and to the protocol above.
{% endhint %}

## 10.1 Why integrity is foundational to the knowledge system

The integrity of the Nexus knowledge system is not a secondary quality. It is the condition under which the system can function as a credible, durable, and globally intelligible architecture. Without integrity, even well-structured content becomes unreliable. Without trust in the corpus, institutional claims weaken, technical coherence fragments, and realization pathways lose legitimacy before they mature.

Integrity, in this context, is not limited to factual correctness. It includes structural truthfulness, consistency across domains, disciplined use of language, clear signaling of authority and maturity, and resistance to drift under pressure from visibility, urgency, or scale. The knowledge system must therefore be constructed and maintained in a way that ensures it remains internally coherent and externally trustworthy over time.

This requirement is especially critical because Nexus operates at the intersection of public purpose, institutional governance, standards architecture, infrastructure for national deployment and real-world consequence. The knowledge base becomes one of the primary surfaces through which that intersection is made legible. If that surface is inconsistent, overstated, or structurally ambiguous, the entire architecture becomes harder to trust.

## 10.2 The nature of trust in Nexus

Trust in the Nexus knowledge system is not rhetorical. It is constructed through disciplined alignment between what the system claims and what it actually governs, between what is described and what is authorized, and between what is visible and what is structurally true.

This trust has multiple dimensions.

First, there is **interpretive trust**: the reader must be confident that terms carry consistent meaning across the corpus and that definitions do not shift depending on context.

Second, there is **authority trust**: the reader must be able to distinguish what is foundational, what is operational, what is participatory, what is canonical, and what is illustrative.

Third, there is **maturity trust**: the reader must know whether a concept, framework, or pathway is established, emerging, or provisional.

Fourth, there is **boundary trust**: the reader must be confident that the system does not imply more than it does, and that it respects its own limits regarding execution, authority, and real-world consequence.

Fifth, there is **continuity trust**: the reader must be able to rely on the system to remain coherent over time, even as it evolves.

These forms of trust are cumulative. They cannot be substituted by tone, branding, or narrative force. They must be built into the structure of the knowledge system itself.

## 10.3 Integrity as alignment across domains

Integrity in Nexus is achieved when all five domains (Organization, Operations, Cooperation, Standardization and Acceleration) remain aligned without collapsing into one another.

Organization must define roles that are reflected in Operations.\
Operations must enact discipline that respects Organization.\
Cooperation must enable participation without redefining authority.\
Standardization must anchor meaning without being diluted by context.\
Acceleration must realize the system without overstating maturity or authority.

When this alignment is preserved, the system speaks with one voice even though it is composed of many parts. When it is not preserved, subtle inconsistencies emerge. A participation document may imply governance authority. A realization document may imply execution readiness. A summary may simplify beyond structural truth. A technical description may drift from canonical meaning. These inconsistencies, if left unaddressed, accumulate into loss of integrity.

The knowledge system must therefore continuously reinforce cross-domain alignment. Integrity is not static. It is maintained through disciplined coherence across all areas.

## 10.4 The discipline of truthful expression

Truthfulness in the Nexus knowledge system is not limited to factual accuracy. It includes the discipline of expressing concepts, states, and capabilities in a way that reflects their actual maturity, scope, and authority.

This discipline requires:

* avoiding premature claims of readiness or deployment;
* avoiding language that implies execution where only routeability or preparation exists;
* avoiding rhetorical compression that merges distinct stages into one;
* avoiding the use of examples as substitutes for doctrine;
* avoiding tone that suggests inevitability where the system remains in formation or expansion.

Truthful expression is particularly important in areas such as compute infrastructure, observatory deployment, routeability architecture, and ecosystem realization. These are areas where enthusiasm, visibility, and ambition can easily lead to overstatement. The knowledge base must instead maintain clarity: describing what is, what is being built, what is possible, and what remains to be done, without conflating those states.

This discipline is not a constraint on ambition. It is what allows ambition to remain credible.

## 10.5 Public meaning and interpretive responsibility

The Nexus knowledge system does not exist in a vacuum. It participates in public discourse across governance, risk, infrastructure, innovation, and development. As such, it contributes to public meaning. That contribution carries responsibility.

Public meaning arises not only from what is explicitly stated, but from how materials are read, cited, interpreted, and circulated. A document written for internal orientation may be quoted externally. A technical note may be read by policy actors. A public explainer may be taken as authoritative doctrine. The knowledge system must therefore anticipate that its materials will travel beyond their original context.

This requires a discipline of **interpretive responsibility**.

Documents should be written in a way that minimizes the risk of misinterpretation when taken out of context. Boundaries should be stated clearly enough that they remain visible even when the text is excerpted. Distinctions among stages, roles, and authority should be explicit enough that they are not lost in summary.

This is not a call for excessive caution or abstraction. It is a call for precision. A precise system is more robust in public discourse than one that relies on implied understanding.

## 10.6 The relationship between integrity and accessibility

There is often a perceived tension between accessibility and rigor. A system that is highly precise may become difficult to read. A system that is highly accessible may risk oversimplification. Nexus must resolve this tension without sacrificing either side.

Accessibility should be achieved through structure, layering and translation, not through dilution of meaning. This means:

* providing clear introductions and overviews for new readers;
* using bounded summaries that orient without redefining;
* maintaining consistent terminology across domains;
* offering multiple entry paths for different reader types;
* structuring documents so that depth is available without overwhelming first contact.

At the same time, rigor must remain visible. Canonical definitions must remain precise. Boundaries must remain explicit. Maturity distinctions must remain intact. Technical and institutional language must retain its exact meaning.

The result should be a knowledge system that is approachable without being approximate, and precise without being inaccessible.

## 10.7 Integrity under growth and scale

As the Nexus knowledge system grows, new contributors, new domains, new deployment pathways, and new forms of participation will emerge. Growth increases both the value and the risk of the system.

The primary risk is **integrity drift**: the gradual weakening of structural clarity as new materials are added without sufficient alignment to the core architecture. This drift often occurs not through deliberate change, but through accumulation of small inconsistencies.

To prevent this, the knowledge system must maintain:

* strict adherence to the five-domain architecture;
* disciplined application of content classes and maturity signaling;
* continuous review for duplication, ambiguity, and misalignment;
* strong editorial governance and stewardship;
* and clear versioning and supersession practices.

Integrity under growth is not achieved by limiting expansion. It is achieved by ensuring that expansion occurs within a stable and visible structure.

## 10.8 Integrity and sovereign compatibility

Because Nexus is designed to respect national sovereignty, the knowledge system must reflect that design in its language, structure and implied authority.

This means:

* avoiding any implication that the system overrides national authority;
* clearly distinguishing between public-good architecture and sovereign decision-making;
* ensuring that national, regional, and host layers are described with respect to their lawful grounding;
* avoiding language that suggests universal adoption or automatic applicability;
* and maintaining clarity about the difference between architecture, readiness, and implementation.

Integrity in this dimension is essential for engagement with public authorities, multilaterals, and national institutions. A knowledge system that appears to blur sovereignty boundaries will be interpreted as overreaching, regardless of its technical or conceptual strength.

The wording rule is exact. "Sovereign" appears on this site only for a public authority's own powers, or as design intent in this form: The systems are "intended to support sovereign and national deployment profiles under national control, subject to evidence for each deployment" \[1]\[5]. It is never used as a product attribute, so no page describes a Nexus system, platform or infrastructure as "sovereign", "sovereign-grade" or "sovereign-ready". National counterparts own the agenda, data and decisions \[5].

## 10.9 The role of correction and transparency

Integrity is not the absence of error. It is the presence of a disciplined response to error. A knowledge system that can correct itself transparently is more trustworthy than one that appears static but hides inconsistency.

Correction should therefore be:

* visible where it affects meaning;
* traceable where it affects authority;
* proportionate to the significance of the issue;
* and integrated into the lifecycle of documents.

Transparency does not require exposing every editorial change. It requires that meaningful changes (those affecting interpretation, authority or structure) are not hidden. This reinforces trust in the system’s capacity to evolve without losing accountability. How a correction is requested and recorded is set out in 10.17.

## 10.10 Integrity as a shared responsibility

While governance structures and editorial roles are essential, integrity ultimately depends on shared responsibility across all contributors and readers.

Contributors must respect domain boundaries, terminology, and maturity distinctions.\
Editors must enforce structural and semantic discipline.\
Domain stewards must maintain coherence within their areas.\
Readers must approach the system with attention to reading rules and entry paths.

Integrity cannot be imposed solely from above. It must be practiced throughout the system. The more participants understand the architecture, the easier it becomes to maintain coherence under scale.

## 10.11 Signals of a high-integrity knowledge system

A knowledge system of high integrity exhibits recognizable characteristics:

* concepts are defined once and used consistently;
* domain boundaries are clear and respected;
* documents signal their authority and maturity;
* cross-references are precise and meaningful;
* revisions are traceable and disciplined;
* public-facing materials align with canonical doctrine;
* realization materials are ambitious but bounded in claim;
* and readers can navigate the system without encountering contradiction.

These signals are not superficial. They are indicators that the underlying architecture is governable.

## 10.12 Final statement on integrity, trust, and public meaning

The integrity of the Nexus knowledge system is inseparable from the integrity of the Nexus architecture itself. It is through the knowledge base that the system becomes legible, interpretable, and transferable across contexts. It is through disciplined language, structure, and governance that trust is built and maintained.

Integrity ensures that the system remains truthful to its own design.\
Trust ensures that others can rely on that truth.\
Public meaning ensures that the architecture contributes constructively to the wider discourse in which it operates.

Together, these elements make the knowledge system not only a repository of information, but a durable foundation for collective understanding, coordination, and action within the Nexus paradigm.

## 10.13 What integrity means in practice

A page has integrity when it is:

* **accurate**: every fact matches its cited source at the stated as-of date;
* **consistent**: its terms mean what their canonical pages say;
* **honest about status**: target, implementation, verification, observation and acceptance are stated separately, and absent evidence is shown as "No record";
* **bounded**: it implies no more authority, readiness or endorsement than its sources support;
* **correctable**: errors are fixed as recorded new versions.

These commitments echo long-standing international practice. Records-management standards describe authoritative records by their authenticity, reliability, integrity (complete and unaltered) and usability \[2]. The United Nations Fundamental Principles of Official Statistics call for professional standards, transparency about sources and methods, and comment on erroneous interpretation \[3]. Nexus is not a records authority or a statistics agency; these are reference points, not claims of conformance.

## 10.14 What a reader can rely on, and how

The five kinds of trust in section 10.2 each rest on a visible control.

| Kind of trust (10.2) | What makes it reliable on this site                                                                                                         |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Interpretive trust   | One canonical page per concept; summaries link to it ([VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md)) |
| Authority trust      | A document record with page class, authority level and document status on every upgraded page                                               |
| Maturity trust       | The five-state grammar, "No record" where evidence is absent, and no merged readiness score \[4]                                            |
| Boundary trust       | The boundary formulas quoted verbatim next to the claims they limit                                                                         |
| Continuity trust     | Version, as-of date, refresh interval and a change log on every upgraded page                                                               |

*Table 1. Reader trust and the control that supports it.*

## 10.15 Claim rules behind truthful expression

Section 10.4 states the discipline; the V3 product-truth directive and the documentation standard draft give it exact rules \[1]\[4]:

* No Nexus system, site, institution, standard or output is called live, active, ready, production-ready, connected, secure, verified, certified, official, government-ready, sovereign-ready, financeable, insurable or compliant, or described as UN-approved or as an official warning, without the named evidence and authorized promotion for the exact scope.
* No title, ownership, signature, adoption date, registration, tax or charitable status, privilege, immunity or mandate is stated without its record. Owner-supplied facts are stated as owner statements.
* Present tense is reserved for what operates now. Targets are written as targets.
* Honest negative states are used: "No edition is on record yet", "No adoption record has been published" \[1].
* Every number sits next to its citation, and every boundary next to the claim it limits \[1].

Where System capability is described, the page carries the status sentence shown at the top of this page \[1].

## 10.16 Accessibility wording

Section 10.6 treats accessibility as structure and layering. Plain-language practice informs the In brief on every page, which aims at a general reading level while the body keeps technical precision \[6]. For web accessibility the site uses this wording only: "Designed to meet WCAG 2.2 level AA; we test pages and fix barriers we find" \[1]\[7]. It never claims to be "fully accessible" or "compliant".

## 10.17 Corrections

A public corrections route has not yet been published. When it is, a correction request should identify:

1. the page address and the version shown in its document record;
2. the exact statement in question;
3. the source that supports the correction, with its date or edition;
4. whether the issue is factual, a status overstatement, a naming error or a boundary problem.

Accepted corrections are dated and listed in the page's editorial record. A correction creates a recorded new version; it is never a silent edit, and earlier versions remain traceable \[1]\[8].

<figure><picture><source srcset="/files/gyQlJELBZujJhg0VgGzq" media="(prefers-color-scheme: dark)"><img src="https://2655483226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEQtittnb4JJQ2YOtd2tk%2Fuploads%2Fgit-blob-91b2b27b8eb9d12a81b074dcbb3bd2558037b80f%2Fknowledge-correction-path-light.png?alt=media" alt="How a correction is handled. A correction request giving the page, version, statement, supporting source and issue type is checked against its source. If supported, the page is issued as a recorded, dated new version and a change-log entry is added. If not, the page is unchanged and the reason is recorded."></picture><figcaption><p><strong>Figure 1.</strong> How a correction is handled. Design of the process; the public route has not yet been published and no correction has yet been recorded through it. Source: the documentation standard and the editorial constitution draft, as of 2026-10-16.</p></figcaption></figure>

<details>

<summary>Text description of Figure 1</summary>

A correction request identifies the page and version, the statement in question, the supporting source and the kind of issue. It is checked against that source, with its date or edition. If the source supports it, the page is issued as a recorded and dated new version, never a silent edit, and an entry is added to the change log in the editorial record, so earlier versions remain traceable. If not, the page is unchanged and the reason is recorded.

</details>

## 10.18 Checks a reader can make

The signals of section 10.11 can be checked on any upgraded page:

* The page has a document record with a version and an as-of date.
* Status statements cite a record or say "No record".
* No readiness, certification or endorsement claim appears without a cited record.
* Institutions are named with register wording and the page links to the institutional order rather than restating it.
* External frameworks are described as alignment or reference.
* The editorial record discloses AI-assisted drafting and the state of human review.

## 10.19 Decision pending

The documentation audit proposes merging this page into [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md). Structural merges await an owner decision; until then, page VIII covers roles and process, and this page covers the integrity commitments those processes serve.

## Next steps

* Read [XI. Final Orientation](/organization/introduction/knowledge/xi.-final-orientation.md) for the final synthesis of the introduction set.
* Return to [Knowledge](/organization/introduction/knowledge.md) to start the main knowledge sequence again with this integrity model in mind.
* Continue into [Organization](/organization/introduction/organization.md) for the first major domain.

## Related pages

* Up: [Knowledge](/organization/introduction/knowledge.md)
* Across: [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md) · [VII. Knowledge lifecycle](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md) · [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md)
* Counterparts: [I. System overview](/organization/introduction/knowledge/i.-system-overview.md) (status note in use) · [III. Status](/organization/introduction/standardization/iii.-status.md) in the Standardization introduction

## Sources

1. Nexus Documentation Standard, draft of 16 October 2026 (status, evidence, tense, claims, versioning and forbidden claims). Internal editorial standard; not published.
2. International Organization for Standardization (2016). *ISO 15489-1:2016 Information and documentation: Records management, Part 1: Concepts and principles*. ISO, Geneva. (URL not verified.)
3. United Nations Statistics Division. *Fundamental Principles of Official Statistics* (General Assembly resolution 68/261). [unstats.un.org](https://unstats.un.org/fpos/). Accessed 2026-10-16.
4. Nexus constitutional directive D-V3-0005, *Product truth, claims and evidence*, and the claim register. Internal record, cited by identifier.
5. Nexus institutional register, *Nexus institutional architecture and participation* (positioning statement). Internal record; owner-confirmed, counsel review pending.
6. International Organization for Standardization (2023). *ISO 24495-1:2023 Plain language, Part 1: Governing principles and guidelines*. ISO, Geneva. (URL not verified.)
7. World Wide Web Consortium (2023). *Web Content Accessibility Guidelines (WCAG) 2.2*, W3C Recommendation. [w3.org](https://www.w3.org/TR/WCAG22/). Accessed 2026-10-16.
8. Nexus editorial constitution, draft (corrections). Internal draft; not published.
9. Nexus Standards. *NS-2: Citation and attribution*, UNI `NXS-STD-ST-000009`, status PROPOSED. [nexustandards.com/standards/ns-2](https://nexustandards.com/standards/ns-2/).
10. Nexus Standards. *NS-1: The UNI and the artifact catalog*, UNI `NXS-STD-ST-000001`, status PROPOSED. [nexustandards.com/standards/ns-1](https://nexustandards.com/standards/ns-1/).
11. Nexus Standards. *NS-4: Structure and drafting of Nexus Standards and documents*, UNI `NXS-STD-ST-000010`, status PROPOSED. [nexustandards.com/standards/ns-4](https://nexustandards.com/standards/ns-4/).
12. GCRI. *Programme status* (programme states and service levels; current level R0). [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). Accessed 2026-10-21.
13. UN Office of the Secretary-General's Envoy on Technology and UNDP (2024). *Universal DPI Safeguards Framework*. [dpi-safeguards.org](https://www.dpi-safeguards.org/).
14. UN General Assembly (2024). *The Pact for the Future*, with the Global Digital Compact. A/RES/79/1. [undocs.org/A/RES/79/1](https://undocs.org/A/RES/79/1).

## Editorial record

* As of: 2026-10-16. Refresh: every 180 days, or sooner when a governing source changes.
* Drafting: AI-assisted. Human review: pending; no named reviewer or approver yet.
* Corrections: a public corrections route has not yet been published. Corrections will be recorded as new dated versions, not silent edits.
* Change log: 2026-10-16 r1, upgraded to the documentation standard draft. Added the Record block, status note and In brief; removed the empty "Part X" heading and fixed heading levels; renamed "Operation" to "Operations"; added the standard sovereignty wording to section 10.8; replaced "sovereign infrastructure" and "sovereign compute" wording; removed em dashes; kept every integrity section and added international reference points, the trust-to-control table, claim rules, accessibility wording, the correction-request content and figure, reader checks, the pending merge decision and sources. 2026-10-16 r2, readable document record and status note; Nexus Standards system codes; Nexus Standards system naming and Nexus Observatory Protocol naming; company references removed; plain-language sources. 2026-10-21 r3, aligned with the latest sources: Where this fits line and current-model note added; institutional roles, standards governance (no standards foundation or protocol authority as an institution), councils (six [Helix councils](/organization/governance-in-operation/councils.md), [CERTs](/organization/governance-in-operation/nwg.md)), [National Nexus](/organization/governance-in-operation/national-nexus.md) and the finance boundary corrected against the Nexus model, the Nexus Consortium model and the Nexus Standards governance; retired labels mapped to successors; sources extended with the public site pages, Nexus Standards identifiers and international frameworks.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.therisk.global/organization/introduction/knowledge/x.-knowledge-base-integrity.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.