# 5.22 Zero-Trust Chain

### **5.22 Trust, Security, and Zero-Trust Chain**

#### **5.22.1 Why trust and security must be treated as a chain rather than a control list**

In the Nexus Ecosystem, trust and security cannot be reduced to a checklist of technical controls, a compliance appendix, or a narrow cyber function sitting beside the “real” architecture. They must be treated as a **chain** because the category is designed to operate across sovereign compute, distributed hosts, public-authority interfaces, continuity-sensitive environments, routeability-facing artifacts, protected participation pathways, lifecycle transitions, degraded states, and multi-actor derivative-document ecosystems. In such a system, security is not only about preventing intrusion. It is about preserving the integrity of identity, state, authority, evidence, publication, handling, service, and correction across the full movement of the chain. Trust likewise is not a vague belief that the system is safe. It is the bounded confidence that the chain can preserve correct actors, correct states, correct permissions, correct transitions, and correct recovery even under stress, compromise, fragmentation, partial failure, or hostile pressure.

This distinction is decisive because traditional “security section” thinking often assumes that once devices are hardened, networks segmented, credentials issued, and audit logs enabled, security is essentially complete. Nexus rejects that framing. The architecture is too dynamic, too distributed, and too consequence-bearing for static perimeter logic to be sufficient. A system can be well defended at the edge and still be constitutionally weak if it cannot answer the following questions:

a) Who is actually trusted to do what, where, and under what present conditions?\
b) What changes when the host degrades, a route narrows, a trust surface weakens, or a lifecycle intervention occurs?\
c) Which identities, artifacts, and state transitions remain valid under disruption, and which must be held, narrowed, or re-authorized?\
d) How does the estate maintain integrity when no single perimeter, single cloud, single institution, or single network can be assumed as the universal safe zone?\
e) How are trust decisions recorded, challenged, corrected, and re-entered after incident, degradation, or replacement?

That is why trust and security must be understood as a **movement chain** rather than a technical appendix. The chain begins with identity and root trust, passes through admission and attestation, persists through runtime enforcement, service and continuity, data and evidence handling, routeability and publication boundaries, lifecycle change, and recovery-to-standing, and continues until retirement and historical retention. Security in Nexus is therefore not merely the defense of assets. It is the preservation of **governed truth under adversarial or uncertain conditions**.

This proposition also matters strategically. A category that claims sovereign relevance but still depends on inherited perimeter assumptions is not yet sovereign-grade. A category that claims public-purpose continuity but cannot sustain bounded trust under partial failure is not yet continuity-grade. A category that claims routeability and capital-interface seriousness but cannot show how trust survives degraded transport, host substitution, lifecycle change, or derivative-document proliferation is not yet institutionally serious. Nexus must therefore state clearly that trust and security are part of its operating constitution.

The final rule of this opening subsection is therefore exact: **trust and security in Nexus shall be read as a chain of bounded identity, authority, state, evidence, and recovery discipline across the whole system, not as a static bundle of controls attached to infrastructure after design is complete**.

***

#### **5.22.2 Trust as bounded confidence, not ambient assumption**

A foundational principle of the Nexus security model is that trust is never ambient. It is never to be assumed merely because something is inside the network, inside an institution, inside a jurisdiction, inside a host, inside a partner arrangement, or inside a previously healthy system. Trust must always be **bounded**, **stated**, and **contextual**. This is the first true meaning of zero-trust in the Nexus sense: not distrust of everything indiscriminately, but refusal to grant unexamined continuity of privilege, authority, or interpretive weight simply because an object, actor, or service was previously accepted somewhere else in the chain.

Bounded trust means several things at once.

a) **Identity-bounded trust**, in which the system asks not “is this actor familiar?” but “what identity is currently asserting itself, under what evidence, through what channel, with what valid scope?”\
b) **State-bounded trust**, in which the system asks not “was this service healthy earlier?” but “what is its present trust state under current path, host, and lifecycle conditions?”\
c) **Context-bounded trust**, in which the system asks not “is this generally allowed?” but “is this appropriate in this host class, route class, degradation state, and authority context?”\
d) **Time-bounded trust**, in which the system recognizes that trust may expire, narrow, or require re-entry after delay, replacement, isolation, or recovery.\
e) **Function-bounded trust**, in which the system distinguishes among reading, writing, approving, publishing, routing, reconciling, overriding, and emergency operation rather than treating all privileges as one permission class.

This matters because the Nexus estate includes many opportunities for false ambient trust.

a) A local operator may be legitimate for host maintenance but not for public-language change.\
b) A regional support function may be legitimate for degraded-state triage but not for sovereign representation.\
c) A node that was trusted in nominal mode may no longer justify the same publication or route posture after transport partition or trust-surface replacement.\
d) A derivative document generated by a valid source may still be invalid for stronger use if its audience, lineage, or update state no longer hold.\
e) A service restored after incident may be functionally available while still untrusted for stronger claims.

The zero-trust doctrine in this whitepaper must therefore be read as an **anti-assumption discipline**. It does not say that nothing can ever be trusted. It says that everything claiming trust must do so through the current chain of identity, state, role, path, and context rather than through inherited comfort. This is especially important for sovereign-compute and public-purpose systems because the most dangerous failures often arise not from total breach, but from stale trust: permissions that survive too long, host assumptions that outlive lifecycle changes, public-safe language that assumes old route classes, or recovery processes that restore service faster than trust.

The final rule is that trust in Nexus shall always be **re-earned at the point of use** according to bounded present conditions. It may accumulate through strong lineage and consistent behavior, but it may never float free from the chain that currently justifies it.

***

#### **5.22.3 Root trust, attestation, and identity anchors**

A zero-trust chain cannot function without **root trust** and **identity anchors**. In Nexus, these do not exist merely to satisfy platform security orthodoxy. They exist because every later claim about actorhood, service legitimacy, node standing, publication authority, route artifact integrity, or recovery-to-standing depends on there being a trustworthy basis from which identity and state can be verified. Without root trust, zero-trust collapses into either unusable suspicion or informal human override. The chain needs something stronger: explicit and bounded anchors from which later trust decisions can be derived and against which later change can be tested.

These anchors include several layers.

a) **Hardware and platform roots**, including trusted hardware elements, secure execution or attestation primitives, and other bounded mechanisms by which platform identity and baseline integrity can be grounded.\
b) **Software and workload identity roots**, including signed images, controlled release provenance, declarative workload identity, runtime attestation, and integrity-bearing boot and update posture.\
c) **Human and institutional identity roots**, including role-bound credentials, multi-party approval keys, bounded role authorities, and organizationally meaningful signers or approvers.\
d) **Artifact and document identity roots**, including signed or version-anchored artifacts, lineage markers, immutable references where appropriate, and explicit record-of-record discipline.\
e) **Trust-policy roots**, including the rules that determine which roots matter for which actions and under which states those actions remain valid.

Attestation is the discipline by which the estate converts those roots into current trust claims. It should not be read narrowly as “TPM proof” or “device health status.” In Nexus, attestation must be broader.

a) **Node and system attestation** confirms class, baseline, integrity posture, and authorized state for runtime participation.\
b) **Service attestation** confirms that services are running from controlled sources under bounded profiles and current permissions.\
c) **Operator and actor attestation** confirms that the actor currently presenting authority is the actor entitled to exercise it under current context.\
d) **Artifact attestation** confirms that route packs, proof objects, annexes, and derivative documents are what they say they are, descend from the right sources, and remain current enough for the use being attempted.\
e) **Recovery and re-entry attestation** confirms that after incident, repair, replacement, or partition, the returning object is not simply functioning, but correctly re-entering the chain.

This is especially important because the Nexus estate is intentionally heterogeneous. It includes rugged and fixed nodes, telecom-integrated systems, remote continuity hosts, mixed-generation hardware, routeability artifacts, public-safe derivatives, and cross-border support layers. A single generic identity model would be too weak. What is needed is one trust architecture with multiple bounded attestation surfaces.

The final rule is that every serious trust claim in Nexus must be traceable back to a current attestation against a declared root and interpreted through a role- and state-aware policy. A familiar thing may be healthy and yet untrusted for a stronger action. An attested thing may be active and yet bounded to narrower use. That is not friction for its own sake. It is the architecture refusing to confuse presence with legitimacy.

***

#### **5.22.4 Least privilege, role separation, and authority segmentation**

A distributed system that wishes to remain trustworthy under pressure must never allow privilege to expand merely because coordination is difficult, timelines are short, or actors are strategically important. This is why the Nexus chain requires strict **least privilege**, **role separation**, and **authority segmentation**. These are not generic security best practices in this context. They are constitutional-operational rules that preserve the integrity of the governance core, the routeability layer, the public-authority interface, the service chain, and the lifecycle chain by ensuring that no one identity, host, or service surface silently accumulates powers that should remain separated.

**Least privilege** means that every actor, service, and workload receives only the minimum permissions needed for its present role and state.

a) A host operator may require local service and observability privileges without having publication or route reclassification privileges.\
b) A regional support cell may require degraded-state triage and continuity coordination privileges without having national standing or sovereign-facing narrative privileges.\
c) A routeability-pack assembler may require bounded access to evidence and host classification without having authority to create execution implication.\
d) A public-safe communications function may require sanctioned derivative views without direct access to restricted or rights-sensitive source material.\
e) A lifecycle repair actor may require hardware and trust-reentry privileges without having authority over host route class or public standing.

**Role separation** means that distinct classes of action remain institutionally and technically segregated even where the same organization participates in more than one layer of the ecosystem. This rule is vital because Nexus is explicitly designed around role-differentiated institutional functions.

a) Evidence stewardship must remain distinct from execution-side consequence.\
b) Standards and profile control must remain distinct from host promotion and market-facing overclaim.\
c) Grievance and safeguards review must remain distinct from actors materially implicated in the complaint.\
d) Public-authority interface work must remain distinct from implied sovereign action.\
e) Recovery and re-entry review must remain distinct from the actors whose urgency is greatest to restore external confidence.

**Authority segmentation** then ensures that privileges do not silently tunnel across layers.

a) Local-domain authority does not automatically imply cluster or national authority.\
b) Technical control does not imply representational authority.\
c) Recovery authority does not imply publication authority.\
d) Support authority does not imply route or standing authority.\
e) Public proximity does not imply institutional mandate.

This segmentation has strategic value beyond security. It reduces capture risk. It reduces accidental overclaim. It reduces the chance that degraded conditions will pressure actors into bypassing constitutional boundaries “just this once.” It also supports correctionability. Where powers are segmented, the chain can later explain which authority acted, within what scope, and whether that scope was valid under current trust state.

The final rule is that least privilege in Nexus is not simply about reducing attack surface. It is about preserving truthful architecture under complexity. The system remains safer because it remains role-correct, and it remains role-correct because no actor or service is allowed to become universally trusted by convenience.

***

#### **5.22.5 Network, host, workload, and artifact zero-trust planes**

A real zero-trust chain must operate across multiple **planes**, because the Nexus estate does not depend on one trust boundary or one technical domain. Trust and security must therefore be distributed and coordinated across at least four major planes: **network**, **host**, **workload**, and **artifact**.

**a) Network plane**

The network plane governs path legitimacy, segmentation, encryption posture, route visibility, traffic-class protection, lateral movement resistance, and transport-aware narrowing. In Nexus, this plane must support path diversity and degraded operation without treating alternate transport or fallback connectivity as implicitly trustworthy. Communications truth must remain richer than “connected” or “not connected,” and degraded or asymmetric paths must narrow authority and claims where necessary.

**b) Host plane**

The host plane governs platform identity, hardware and firmware integrity, local control boundaries, interface exposure, physical and logical compartmentalization, lifecycle-sensitive trust events, and host-state posture under degradation or replacement. This plane is particularly important because hosts in Nexus are heterogeneous: public-authority, telecom, industrial, remote, research, community-facing, and corridor-sensitive. Zero-trust cannot therefore depend on one generic host security profile.

**c) Workload plane**

The workload plane governs the identity and permissions of services, models, pipelines, agents, connectors, and workflow engines running on the estate. It ensures that software units prove who they are, what they are allowed to do, what data or state they may touch, and under what current host and route conditions they remain valid. This is essential because a sovereign-compute estate increasingly depends on orchestrated workloads rather than static applications.

**d) Artifact plane**

The artifact plane governs trust in proofs, route packs, derivative documents, signed outputs, release bundles, policy objects, public-safe summaries, and other non-runtime objects that nevertheless influence routeability, standing, public interpretation, or operational behavior. This plane is often overlooked in conventional security design. In Nexus it is indispensable because documentary and proof-bearing objects themselves can become vectors of distortion, stale trust, or unauthorized consequence if not controlled.

The value of these planes is that they allow the chain to localize trust decisions correctly.

a) A path may be degraded while the host remains healthy.\
b) A host may be healthy while one workload becomes untrusted.\
c) A workload may be valid while a derivative artifact becomes stale or improperly widened.\
d) A document may be correctly signed yet invalid for current use because the route or host state changed underneath it.\
e) A service may be restored locally while the network and artifact planes remain in narrowed state.

This plane-based model is one of the strongest reasons the Nexus architecture can remain honest under complexity. It avoids collapsing everything into device security or network security. It recognizes that modern public-purpose and sovereign systems are equally vulnerable to compromised documents, stale route packs, over-privileged orchestrators, and deceptive recovery narratives. Zero-trust must therefore live wherever meaningful action can be taken or meaningful claims can be made.

The final rule is that no trust decision in Nexus should be treated as complete unless the relevant planes have all been considered for that action. A healthy network does not redeem a bad artifact. A healthy host does not justify an over-privileged workload. A signed derivative does not override a degraded route state. Plane-aware zero-trust is therefore part of the category’s semantic integrity, not only its cyber posture.

***

#### **5.22.6 Zero-trust under degraded, partitioned, and recovery conditions**

A system that is zero-trust only in nominal conditions is not yet serious enough for the environments Nexus intends to serve. Trust and security must therefore hold under **degraded**, **partitioned**, **isolated**, and **recovery** conditions. This is one of the hardest but most important demands the architecture places on itself. Under pressure, many systems quietly revert to ambient trust, emergency bypass, undocumented human override, or flattened segmentation. Nexus must reject that drift. It must instead make the trust chain more explicit under stress, not less.

In degraded or partitioned conditions, several principles become decisive.

a) **Trust must narrow, not disappear silently.** The system may continue bounded protected functions, but it must also reduce authority, publication scope, route implications, and cross-domain assumptions where path confidence, synchronization, or central policy freshness weakens.

b) **Local trust posture must remain bounded and declared.** A host or node operating in isolation may remain trusted for a narrower protected-function set without being treated as equivalent to full nominal standing.

c) **Emergency utility must not become emergency overreach.** Degraded-mode operation may justify narrowed local actions and continuity behavior, but not unbounded privilege expansion or permanent bypass of role segmentation.

d) **Recovery requires trust re-entry, not just technical rejoin.** Once communications or services return, the chain must still verify backlog, artifact freshness, trust anchors, workload state, and route implications before stronger authority or claims are restored.

e) **State and authority must remain visible to humans.** Under degraded conditions, human operators and public-authority counterparts must not be forced to infer whether the system is in trusted nominal mode, trusted narrowed mode, or trust-limited continuity mode.

This doctrine is strategically important because many of the hosts and pathways the architecture serves are precisely those where degraded conditions are not edge cases. Remote and austere settings, continuity-critical public systems, telecom and corridor infrastructures, public-authority crisis contexts, and partition-tolerant sovereign deployments all require bounded useful function under broken assumptions. Zero-trust must therefore be compatible with continuity, not hostile to it.

The correct model is neither “trust everything locally because central conditions are broken” nor “stop everything because central trust confirmation is unavailable.” It is a third path: **bounded local trust under declared degraded conditions, with explicit reduction of scope and explicit recovery-to-standing processes**.

The final rule is that zero-trust in Nexus shall be designed for impaired reality as much as for ideal architecture. A trust model that collapses under partition is not yet sovereign-grade. A trust model that survives by becoming invisible is not yet legitimate. The system must remain both usable and honest under stress.

***

#### **5.22.7 Security of data, evidence, routeability, and public-safe artifacts**

The zero-trust chain in Nexus must also protect not only hosts, services, and paths, but the **informational objects** through which the ecosystem generates governance, routeability, public understanding, and institutional coordination. This includes data, evidence, proof objects, routeability artifacts, public-safe derivatives, lifecycle records, correction notices, and standing-relevant documents. In many systems, security focuses on infrastructure while documentary integrity is treated as records management. In Nexus, that separation is too weak. Documentary and evidentiary artifacts can themselves carry route, standing, public-language, and institutional consequence. Their compromise therefore matters constitutionally, not just administratively.

The security of these objects requires several distinct controls.

a) **Integrity control**, so that the chain can determine whether an artifact has been altered, truncated, selectively repackaged, or otherwise compromised.

b) **Lineage control**, so that derivatives, summaries, localized packs, and route-facing objects remain traceable to stronger sources and current states.

c) **Audience control**, so that artifact exposure matches handling class, route class, and purpose, especially for public-safe or protected-participation-sensitive materials.

d) **Freshness control**, so that stale route artifacts, superseded host packs, outdated route classes, or invalid standing summaries are not still relied upon merely because they are well formatted or widely circulated.

e) **Redistribution control**, so that material artifacts do not continue traveling without regard to later correction, withdrawal, or narrowing.

f) **Consequence awareness**, so that the system recognizes that a corrupted or stale routeability pack can create more harm than a noisy infrastructure alert if it influences public or institutional interpretation incorrectly.

This is one of the main points of convergence between the security chain and the derivative-document chain. A route pack is not safe merely because the source system was secure. A public-safe summary is not trustworthy merely because it came from an authorized team. A localized host brief is not safe merely because it was once accurate. Artifact security must include the question: **is this still valid for this use, for this audience, under this current host, route, and trust state?**

The final rule is that the security of informational objects in Nexus shall be treated as part of trust, routeability, and public integrity, not merely as content management. The system becomes safer when it protects meaning-bearing artifacts with the same seriousness it protects compute and transport.

***

#### **5.22.8 Security and trust interaction with public-authority, routeability, and execution boundaries**

Trust and security do not stop at the technical edge of the estate. They interact directly with **public-authority interfaces**, **routeability**, and **execution boundaries**. This interaction is critical because a large proportion of the most consequential harms in a system like Nexus do not arise from brute-force compromise alone. They arise when authority is inferred where none exists, when routeability artifacts are overread, when public proximity is treated as sovereign trust, when security posture is assumed to imply policy legitimacy, or when degraded trust states are not reflected in outward-facing behavior.

Several interaction rules are therefore essential.

a) **Public-authority visibility does not create ambient trust.** A pathway’s proximity to ministries, agencies, or public operators does not reduce the need for explicit identity, role, and state validation. Public-sector context raises the need for bounded trust; it does not dissolve it.

b) **Routeability objects require trust posture awareness.** A routeability pack assembled under stale host truth, narrowed continuity posture, degraded path confidence, or outdated route class must not circulate as though none of those conditions existed.

c) **Execution boundaries require trust boundaries.** The ecosystem must ensure that actors and services involved in routeability, public-authority interfacing, and external presentation cannot silently drift into execution-side implication through authority overreach, document inflation, or artifact misuse.

d) **Public-safe language must remain trust-state aware.** A derivative may be formally approved and yet no longer safe for public or strategic use because the underlying host, route, or trust state changed.

e) **Recovery of technical trust does not equal recovery of representational authority.** After incident or degradation, publication, route, and sovereign-facing posture may remain narrower than local runtime health would suggest.

This interaction is especially important because the most dangerous failures at this boundary often look polished rather than chaotic. A clean executive brief based on stale standing can be more harmful than a visible alarm. A route pack circulated after trust narrowing can create execution-side misinterpretation even if no system was hacked. A public-authority audience may overread technical maturity into policy legitimacy if the chain does not preserve its boundaries.

The final rule is that trust and security in Nexus shall always be evaluated not only against infrastructure attack surfaces, but against the risk of **authority distortion**, **route inflation**, and **public over-implication**. A secure system that still allows false consequence to spread is not yet secure enough for this category.

***

#### **5.22.9 Security incident, compromise, and trust-restoration chain**

A trustworthy zero-trust architecture must also be able to handle **security incidents**, **suspected compromise**, **confirmed compromise**, and **trust restoration** without collapsing into either panic or concealment. In Nexus, incident handling is not merely technical containment. It is a chain that runs through service state, host truth, publication posture, routeability, derivative-document integrity, public-authority relevance, and later recovery-to-standing. This is necessary because security incidents can affect meaning long after the immediate technical symptom has been mitigated.

The incident and trust-restoration chain should therefore include several stages.

a) **Detection and suspicion**, where anomalous behavior, trust mismatch, integrity failure, unexplained state divergence, artifact irregularity, or actor misuse is detected or reasonably suspected.

b) **Containment and narrowing**, where permissions, publications, routeability objects, service scopes, host claims, and artifact circulation may need to narrow while the truth is established.

c) **Classification**, where the incident is understood not only as a technical event but as a host, route, trust, documentary, or public-language event.

d) **Evidence preservation**, where logs, artifacts, proof objects, and state transitions are protected for later review and correction.

e) **Restoration**, where compromised or uncertain trust surfaces are rebuilt, identities re-established, artifacts revalidated, and affected services re-enter under bounded conditions.

f) **Recovery-to-standing**, where the system determines whether stronger publication, host, or route claims may resume or whether residual narrowing remains necessary.

This chain matters because compromise in Nexus is often **multi-domain**. A credential misuse event may affect routeability packs and public-safe derivatives. A host compromise may invalidate route language. A stale or tampered derivative may force broader publication correction. A suspicious recovery process may justify local runtime restoration while keeping sovereign-facing or capital-facing artifacts narrowed. The chain must therefore preserve more nuance than “incident resolved.”

The final rule is that security restoration in Nexus is complete only when:

a) the technical vector is contained or removed;\
b) the relevant trust anchors and permissions are re-established;\
c) affected artifacts and route objects are revalidated or withdrawn;\
d) publication and public-language posture are corrected; and\
e) the system has explicitly determined what standing or route states survive, narrow, or require later restoration.

Anything less may be partial recovery, but not full trust restoration.

***

#### **5.22.10 Final doctrine of the trust, security, and zero-trust chain**

The final doctrine of this section is that the Nexus Ecosystem shall operate through a whole-of-chain trust, security, and zero-trust architecture in which identity, authority, state, path, artifact, and recovery are continuously bounded, role-aware, context-aware, and evidence-linked. This doctrine rejects ambient trust, perimeter-only confidence, and recovery-by-assumption. It affirms that security in a sovereign-grade, public-purpose, routeable ecosystem is not only about resisting intrusion. It is about preserving correct meaning and correct authority under nominal, degraded, partitioned, recovering, and post-incident conditions alike.

That doctrine yields the following controlling rules.

a) Trust shall always be bounded and current, never ambient or inherited merely by proximity, familiarity, or prior healthy state.\
b) Root trust, attestation, and identity anchors shall support all stronger claims of actorhood, service legitimacy, artifact integrity, and recovery-to-standing.\
c) Least privilege, role separation, and authority segmentation shall remain fundamental constitutional controls across local, regional, national, routeability, publication, lifecycle, and safeguards surfaces.\
d) Network, host, workload, and artifact planes shall all be treated as zero-trust domains requiring distinct but coordinated trust decisions.\
e) Degraded, partitioned, isolated, and recovery conditions shall narrow trust explicitly rather than collapsing into silent ambient trust or silent overreach.\
f) Security of data, evidence, routeability, and derivative artifacts shall be treated as part of route, public, and institutional integrity, not merely content management.\
g) Public-authority, routeability, and execution-boundary interfaces shall remain trust-state aware and shall not convert technical health into policy legitimacy or routeability into execution authority.\
h) Security incidents and trust-restoration events shall propagate into service, route, publication, and derivative-document correction where necessary.\
i) Recovery of runtime or transport alone shall never be treated as full restoration of trust, authority, or standing.\
j) The legitimacy of Nexus as a sovereign-grade and public-purpose-grade ecosystem depends materially on this chain remaining visible, bounded, correctionable, and operational under stress.

The strategic consequence of this doctrine is substantial. It allows the whitepaper to claim not only that Nexus can run important systems, but that it can preserve disciplined trust in those systems when conditions are least forgiving. It supports sovereign credibility because it refuses ambient institutional trust. It supports public-purpose credibility because it narrows safely rather than lying about continuity. It supports routeability credibility because it preserves the boundary between evidence-backed readiness and unearned consequence. And it supports long-horizon growth because controlled diversity does not become uncontrolled trust sprawl. That is the final doctrine of the trust, security, and zero-trust chain.


---

# Agent Instructions: 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:

```
GET https://docs.therisk.global/organization/acceleration/nexus-compute/v.-whole-of-chain/5.22-zero-trust-chain.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.