diff --git a/docs/cli/Guides/tgwui.md b/docs/cli/Guides/tgwui.md
index e12f58ef..87602534 100644
--- a/docs/cli/Guides/tgwui.md
+++ b/docs/cli/Guides/tgwui.md
@@ -231,4 +231,8 @@ The most important statuses (see the [full list](/fundamentals/orders#compute-or
 - **Processing**: The compute is executing the order inside a TEE. Your model is either already available or will be available soon.
 - **In Queue**: The order is waiting for the compute to become available. This status appears only if the compute is overloaded with orders. If this status persists for a few minutes, place a new main order the same tunnel order and engine configuration but another compute offer.
 - **Done**: The order is completed successfully and the model's UI is no longer available.
-- **Error**: The order completed with an error. [Download the order results](/cli/commands/orders/download-result) to get more information about the error.
\ No newline at end of file
+- **Error**: The order completed with an error. [Download the order results](/cli/commands/orders/download-result) to get more information about the error.
+
+## Support
+
+If you have any issues or questions, contact Super Protocol on [Discord](https://discord.gg/superprotocol) or via the [contact form](https://superprotocol.zendesk.com/hc/en-us/requests/new).
\ No newline at end of file
diff --git a/docs/fundamentals/certification.md b/docs/fundamentals/certification.md
index a943c6b5..0dfd2161 100644
--- a/docs/fundamentals/certification.md
+++ b/docs/fundamentals/certification.md
@@ -5,37 +5,67 @@ slug: "/certification"
 sidebar_position: 6
 ---
 
-Super Protocol uses a certification system for signing data, verifying signatures, and ensuring applications operate within a trusted confidential computing environment. Verified data is published on the blockchain on behalf of confidential containers, allowing anyone to validate application integrity and ensure confidentiality. End users only interact with issued certificates and verify signatures, while the complexities of Remote Attestation are seamlessly managed in the background.
+The Super Protocol Certification System is a hierarchical infrastructure for managing trust in confidential computing environments. The main purpose of the system is to create a valid chain of X.509 certificates for any applications running in <a id="tee"><span className="dashed-underline">Trusted Execution Environments</span></a> (TEEs). The Certification System itself also operates within TEEs, ensuring the entire chain is rooted in hardware-based trust.
 
-All the system components are open-source, ensuring transparency and verifiability.
+The Certification System performs remote attestation under the hood, but exposes a familiar X.509-style certificate chain on the surface. This allows any verifier (a user, an auditor, or an automated service) to validate that:
+
+- The execution took place within a TEE.
+- The certificate chain leading to the workload is valid and trusted.
+
+The Certification System can function as an independent, standalone service. In this capacity, it could serve external companies and users who need to establish certificate chains for their own confidential computing applications.
+
+Note that the system is not responsible for validating what an application does internally. Its primary role is to issue certificates to trusted confidential environments, forming a cryptographically verifiable trust chain.
+
+All system components are planned to be open-sourced, improving transparency and verifiability.
 
 ## Architecture
 
-The backbone of the system is a hierarchical structure of <a id="ca"><span className="dashed-underline">Certification Authorities</span></a> operating inside <a id="tee"><span className="dashed-underline">Trusted Execution Environments</span></a> (TEE)—Intel SGX enclaves.
+The Certification System is organized as a hierarchy of <a id="ca"><span className="dashed-underline">Certification Authorities</span></a> (CAs) that establishes trust for TEEs through a standard certificate chain. Every CA operates within a TEE—Intel SGX enclave.
 
 <img src={require('./images/certification-system-architecture.png').default} width="auto" height="auto"/>
 <br/>
 <br/>
 
-The Root Certification Authority (*Root CA*) is located at the highest hierarchical level. At the start, Root CA generates a self-signed certificate, embedding the SGX attestation quote.
+The chain consists of three levels:
+
+- Root CA is the top-level certificate authority that establishes the trust anchor for the entire system. At the start, it generates a self-signed certificate, embedding the SGX attestation quote.
+- SubRoot CAs are intermediate certificate authorities. They submit their quotes and public keys to the Root CA and request certificates. The Root CA verifies these incoming requests and then issues and signs certificates for the SubRoot CAs. Once a SubRoot CA is certified by the Root CA, it can certify any TEE-backed environment that proves it is actually confidential.
+- End certificates are issued to specific workloads, entire <a id="ca"><span className="dashed-underline">Confidential Virtual Machines</span></a> (CVMs) running in TEEs, and in some other cases. These certificates are not CAs and cannot be used to sign or issue other certificates.
+
+Each level in the hierarchy receives its certificate from the level above, creating a chain of trust that ultimately traces back to the Root CA.
+
+## Trusted Loader
 
-SubRoot Certification Authorities (*SubRoot CAs*) are located at the next hierarchical level. These submit their quotes and public keys to the Root CA and request certificates. The Root CA verifies these incoming requests and then issues and signs certificates for the SubRoot CAs.
+Trusted Loader is a special service that prepares and launches the workload associated with an <a id="order"><span className="dashed-underline">order</span></a> inside a CVM running in a TEE. It runs in a privileged position within the execution environment, allowing it to access the underlying attestation capabilities of the platform. Workloads themselves do not have such access.
 
-The SubRoot CAs, in turn, issue and sign certificates for <a id="order"><span className="dashed-underline">orders</span></a> by request.
+Trusted Loader also:
+
+- Collects hashes of the workload and its components.
+- Verifies workload integrity before execution starts.
+- Requests end certificates.
+
+All end certificates are requested and received by Trusted Loader. Other components do not interact directly with Certificate Authorities. Trusted Loader may request certificates in several cases:
+
+- At startup. The certificate confirms that the confidential environment is correctly configured and that the attestation challenge (TDX, SEV-SNP, etc.) matches expectations.
+- When generating session keys. The certificate is included in the session key structures used during execution.
+- When forming a <a id="tcb"><span className="dashed-underline">TEE Confirmation Block</span></a> (TCB). The certificate is embedded into TCB, which also includes system information and measurements.
+- When deploying an order. An order-specific certificate is issued and delivered, along with cryptographic keys, to the order's execution environment.
 
 ## Order certificates
 
-The issuing of order certificates involves Trusted Loader—a software mechanism developed by Super Protocol to load and run applications within a TEE. Trusted Loader operates inside the Confidential VM that executes the order. This Confidential VM may be deployed within a CPU-based or CPU/GPU-augmented TEE using technologies such as Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing, or others, making the system TEE-agnostic.
+Trusted Loader requests a dedicated order-specific certificate when an order is prepared for execution. This certificate includes order-specific data, such as the hash of workload information.
 
-To receive an order certificate, the Trusted Loader sends a request to a SubRoot CA providing the quote and a public key. The SubRoot CA verifies the quote, issues the order certificate, and signs it with the provided public key.
+Trusted Loader places the order certificate as a file into the order's execution environment. There, it can be used by the order itself to prove that it was launched within a confidential environment.
+
+Note that the Certification System does not determine whether a CVM is correct or compromised. If a CVM runs in a confidential environment, it can obtain certificates. However, differences in hashes are visible in the certificate chain and can be detected by any verifying party.
 
 ### Order validation
 
-Orders in Super Protocol are created with necessary input data. This execution environment is referred to as *Workload Info*.
+Orders in Super Protocol are created with a workload description known as *Workload Info*.
 
-The Workload Info includes an array called `runtimeInfo[]` with metadata about <a id="solution"><span className="dashed-underline">solutions</span></a> and datasets used in the order. Each such order component has an entry in this array, which includes:
+Workload Info includes an array called `runtimeInfo`. It contains information about <a id="solution"><span className="dashed-underline">solutions</span></a> and <a id="data"><span className="dashed-underline">data</span></a> associated with the order. Each such order component has an entry in this array, which includes:
 
-- Type
+- Type (solution or data)
 - Hash
 - Size
 - Signature key hash (optional)
@@ -43,9 +73,13 @@ The Workload Info includes an array called `runtimeInfo[]` with metadata about <
 
 The hash of the Workload Info is included in the order certificate.
 
-Trusted Loader generates and publishes a report in the blockchain, allowing anyone to validate the order. This order report includes:
+Before order execution begins, Trusted Loader checks the integrity of the full workload composition (solutions, data, and configuration). The order proceeds only if this verification succeeds.
+
+Trusted Loader also generates and publishes a report to the blockchain, allowing any verifier to validate the order. The report includes:
 
 - The public components of all the certificates in the chain
 - Workload Info:
     - Order creation date
-    - The `runtimeInfo[]` array
\ No newline at end of file
+    - The `runtimeInfo` array
+
+The immutable nature of blockchain prevents any further alterations to the report once it is published. The report enables verifiers to confirm what exactly was launched and that the certificate corresponds to that specific workload.
\ No newline at end of file
diff --git a/docs/fundamentals/images/certification-system-architecture.png b/docs/fundamentals/images/certification-system-architecture.png
index 4e4ffd05..32eead65 100644
Binary files a/docs/fundamentals/images/certification-system-architecture.png and b/docs/fundamentals/images/certification-system-architecture.png differ
diff --git a/src/theme/Layout/index.js b/src/theme/Layout/index.js
index eeac7d18..980964c8 100644
--- a/src/theme/Layout/index.js
+++ b/src/theme/Layout/index.js
@@ -87,9 +87,21 @@ export default function Layout(props) {
           ᐧ A <i>tunnel client</i> hosts a web server; it remains hidden behind the tunnel server and protected from external threats.
       </Tooltip>
 
+      <Tooltip anchorSelect="#tcb">
+        <i>TEE Confirmation Block</i> (TCB) contains a unique device ID, equipment benchmark results, <br/>various hashes, device signature, and a certificate chain for signature verification.<br/><br/>
+        
+        Trusted Loader generates and publishes TCB on the blockchain every 24 hours.
+      </Tooltip>
+
+      // Stabs and abbreviations
+
       <Tooltip anchorSelect="#cvm">
         Confidential Virtual Machine
       </Tooltip>
+
+      <Tooltip anchorSelect="#tl">
+        Trusted Loader
+      </Tooltip>
     </>
   );
 }
\ No newline at end of file