# Risk Disclosure Framework

<figure><img src="/files/hIKHqRe14UoO99nzzSQP" alt=""><figcaption></figcaption></figure>

<br>

> **Note:** This document defines the risk identification, management, and disclosure standards operated by Assemble AI in connection with the ASM token and the NS3 platform. It is intended to support exchange compliance review, community transparency, and the issuer's fiduciary obligations.

### 1. Overview

Assemble AI operates an internal standard framework to proactively identify and manage risks across the ASM token ecosystem and to minimize information asymmetry among exchanges, users, and the community.

The framework is designed to fulfill both the fiduciary duties of a token issuer and the cooperation obligations toward listing exchanges. It moves beyond a simple enumeration of risks and adopts a lifecycle structure spanning **identification → assessment → escalation → disclosure → post-incident review**.

### 2. Risk Taxonomy

Risks associated with the ASM token and the NS3 business are classified and managed under the following five categories. Each category defines specific risk items and the operational controls applied to them.

#### 2.1 Operational Risk

Risks affecting the continuity of the NS3 platform and business operations.

| Risk Item                                    | Control                                                                   |
| -------------------------------------------- | ------------------------------------------------------------------------- |
| News pipeline failure                        | Multi-source data redundancy and automated failover                       |
| Multilingual translation quality degradation | 16-language quality monitoring and user feedback loop                     |
| System overload and downtime                 | Scalable cloud-based infrastructure and regular stress testing            |
| Data accuracy and reliability                | Cross-validation across multiple sources and algorithmic integrity checks |

#### 2.2 Market Risk

Risks related to the token market and liquidity conditions.

| Risk Item                     | Control                                                                |
| ----------------------------- | ---------------------------------------------------------------------- |
| Price volatility              | Market-maker operating standards and periodic review                   |
| Insufficient liquidity        | Multi-exchange pair operation and diversification of MM counterparties |
| Circulating supply changes    | Pre-disclosure of vesting schedules and on-chain verifiability         |
| Funding and operating capital | Diversified funding options, cost optimization, and reserve management |

#### 2.3 Regulatory Risk

Risks arising from changes in the regulatory environment and compliance obligations across relevant jurisdictions.

| Risk Item                                  | Control                                                                                        |
| ------------------------------------------ | ---------------------------------------------------------------------------------------------- |
| Changes in licensing requirements          | Continuous monitoring of regulatory trends and acquisition of necessary licenses               |
| Delayed response to regulatory change      | Legal advisory structure and flexible business model design                                    |
| AML/CFT non-compliance                     | Designated compliance officer and regular AML/CFT training                                     |
| Failure to monitor suspicious transactions | Structured transaction monitoring workflow and immediate response protocol                     |
| Exposure to sanctioned entities            | Ongoing updates against OFAC, UN, and EU sanctions lists and high-risk customer identification |

#### 2.4 Technical and Security Risk

Risks related to technical infrastructure and information security.

| Risk Item                            | Control                                                                                                        |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| Smart contract vulnerabilities       | Periodic external audits and an active bug bounty program                                                      |
| Infrastructure intrusion and hacking | Penetration testing, security audits, and layered defense architecture                                         |
| Key management (Treasury, multisig)  | Multisig and cold wallet operation; use of verified institutional-grade custody                                |
| User data exposure                   | Application of current encryption standards and compliance with applicable data protection laws including GDPR |
| Phishing and social engineering      | Standardized secure communication channels and periodic employee security training                             |

#### 2.5 Counterparty Risk

Risks related to external partners and service providers.

| Risk Item                                 | Control                                                                      |
| ----------------------------------------- | ---------------------------------------------------------------------------- |
| Changes in major data supply partnerships | Codified partnership SLAs and backup supply arrangements                     |
| Exchange and custody counterparties       | Counterparty diversification and periodic credit and operational risk review |
| External auditors and legal advisors      | Multiple advisory relationships and conflict-of-interest review              |

> **Warning** Each risk is assessed on an **Impact (High/Medium/Low) × Likelihood** matrix. Any item rated High-High automatically enters the Tier 3 escalation procedure or above.

### 3. Escalation Structure

A four-tier internal escalation structure is operated, with clearly defined responsibilities and service level agreements at each tier.

| Tier       | Responsible Party                 | Role                                                 | SLA                        |
| ---------- | --------------------------------- | ---------------------------------------------------- | -------------------------- |
| **Tier 1** | Operations Team (24/7 monitoring) | Initial detection, classification, and logging       | Within 1 hour of detection |
| **Tier 2** | Department Lead                   | Impact analysis and response planning                | Within 4 hours             |
| **Tier 3** | C-Level (CEO / CTO / CCO)         | Material event determination and disclosure approval | Within 12 hours            |
| **Tier 4** | Board and External Disclosure     | Official disclosure and exchange notification        | Within 24 hours            |

#### 3.1 Material Event Criteria

Any event meeting one or more of the following criteria automatically enters Tier 3 escalation or above.

* Events affecting the structure of the token economy
* Decisions involving a change of 5% or more in circulating supply
* Listing, delisting, or trading pair changes on major exchanges
* Formal inquiry or investigation initiated by a regulatory authority
* Security incidents (hacking, key compromise, contract exploit, large-scale phishing campaigns)
* Identification of suspicious transactions under AML/CFT review or exposure to sanctioned parties
* Changes in key executive personnel
* Material changes to the business model

### 4. Disclosure Channels

Channels are operated differentially based on the nature and urgency of the event.

| Channel                          | Purpose                                     | Operating Principle                     |
| -------------------------------- | ------------------------------------------- | --------------------------------------- |
| **X (Twitter)**                  | Immediate first-line disclosure             | Breaking events disclosed within 1 hour |
| **CMC Community**                | Formal periodic and ad-hoc updates          | Standardized format, English baseline   |
| **Official Website Docs**        | Detailed analysis and post-mortem reporting | Within 72 hours after event resolution  |
| **Direct Exchange Notification** | Pre-disclosure of material events           | Official email with C-Level signature   |

#### 4.1 Layered Disclosure Principle

To avoid single-channel dependency, the same information is distributed in three sequential layers with a consistent message.

* **Layer 1 (Immediate)**: Fact-only disclosure immediately following event detection. Primary channel: X.
* **Layer 2 (Summary)**: Summary of impact scope, ongoing status, and expected timeline. Primary channel: CMC Community.
* **Layer 3 (Detailed)**: Root cause analysis, remediation, and post-mortem. Primary channel: Official Website Docs.

#### 4.2 Exchange Pre-Notification Principle

Events meeting the Material Event Criteria are **notified to exchange compliance contacts prior to public disclosure**. Notification is delivered via official email signed by a C-Level executive, with a minimum interval of 30 minutes between pre-notification and public disclosure.

### 5. Design Principles

The framework is built on the following operating principles.

#### 5.1 Speed over Completeness in First Disclosure

First-layer disclosure prioritizes speed over completeness. Only verified facts are released concisely, with further detail provided in subsequent layers. Information vacuums invite speculation; partial but prompt disclosure is more effective in preserving market trust.

#### 5.2 Channel Redundancy

Single-channel dependency exposes disclosure to reach failure, censorship, and platform policy changes. The same information is distributed through at least two independent channels.

#### 5.3 Standardized Format

All disclosures follow a predefined format covering event overview, scope of impact, response measures, and forward timeline. Standardization improves the review efficiency of exchange compliance teams and minimizes interpretive errors within the community.

#### 5.4 Pre-Disclosure Consultation for Material Decisions

Material decisions, such as changes to the token economy, are accompanied by a minimum 72-hour consultation window. This mitigates the trust erosion that may arise from unilateral decisions.

#### 5.5 Continuous Update Until Resolution

Periodic updates are maintained at intervals of no longer than 24 hours until the event is resolved. Silence is treated as equivalent to a disclosure obligation breach.

#### 5.6 Separation of Routine and Incident Reporting

Routine operational reporting and ad-hoc incident reporting are separated by channel, format, and approval procedure. Conflation of the two undermines readability and credibility.

#### 5.7 Continuous Education and Awareness

The effectiveness of the framework depends on the awareness of personnel and the community. Regular training programs are operated in the areas of information security, regulatory compliance, and transaction monitoring, and adherence to internal security checklists is reviewed quarterly.

### 6. Commitments to Exchange Partners

Assemble AI provides the following assurances to exchange partners.

1. **Material Event Pre-Notification**: Exchanges are notified prior to public disclosure through an official channel signed by a C-Level executive.
2. **Continuous Updates**: Updates are provided regularly throughout the lifecycle of an event so that no information asymmetry persists between resolution and public disclosure.
3. **Response SLA Compliance**: Additional information requests from exchanges are addressed within 24 business hours, with direct C-Level engagement available when required.
4. **Periodic Operational Reporting**: Quarterly operational reports are delivered to designated exchange points of contact so that the risk posture of the ASM token remains visible at all times, not only during incidents.
5. **AML/CFT Cooperation**: Inquiries from exchanges regarding suspicious transactions or sanctioned-party exposure are addressed immediately through the designated compliance officer.

### 7. Continuous Improvement

This framework is maintained as part of an ongoing operating cycle rather than as a static document.

* **Quarterly Review**: The risk assessment matrix is recalibrated by category each quarter.
* **Incident-Driven Revision**: Findings from every Material Event post-mortem are incorporated into the framework.
* **Ad-Hoc Revision for Regulatory Change**: Material changes in relevant jurisdictions trigger immediate revision.
* **Community Feedback Integration**: Feedback collected through the CMC Community and X channels is incorporated into the quarterly review cycle.

> **Success:** This framework is subject to quarterly review and may be amended on an ad-hoc basis in response to material regulatory developments or changes in the operating environment.


---

# 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.ns3.ai/white-paper/risk-disclosure-framework.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.
