Data Architecture

1. Introduction to the FSDM Layered Model

The FSDM (Framework for Structured Data Modeling) layered model aims to build a structured, interpretable, and easily composable private data product system. By dividing data products into five logical layers, it helps customers understand underlying data and apply it to high-level business scenarios, forming a complete closed loop that enhances data utilization efficiency and depth.

The FSDM model consists of five layers:

1. A Layer | Information Model Layer — What do we store?

2. B Layer | Conceptual Model Layer — How is the information related?

3. C Layer | Logical Indicator Layer — Logical indicator system

4. C′ Layer | Physical Indicator Layer — Data fields and table structures

5. D Layer | Application Layer — Business scenarios and strategy design

---

2. Detailed Description of Each Layer

2.1 A Layer | Information Model Layer — What Do We Store?

{
    "user": "KOL_A (Tier1)",           // Who (user tag)
    "community": "Telegram_Official",  // Where (community tag)
    "content": "$PEPE listing soon!",  // What was said (raw text)
    "event": "exchange_listing",       // About what event (event tag)
    "symbol": "PEPE"                   // Which project is affected (token tag)
}

• Core Objective: Define the "atomic unit" and core dimensions of the data product, clarifying the boundaries and structure of basic information.

• Key Dimensions:

  • Who (User): Identity and attributes of the speaker.

  • Where (Community): Platform and group where the information originated.

  • What (Text Content): Specific content and semantics of the message.

  • About What (Event): Market events or themes involved.

  • Which Project Affected (Token): Associated crypto asset or project.

These five dimensions form the foundation of the data, and all tags and metrics are built around them.

---

2.2 B Layer | Conceptual Model Layer — Relationships and Causality Between Information

• Core Objective: Clarify the logical relationships and business causality between information in Layer A, forming an easily understandable conceptual graph.

• Example Relationships:

  • User activity influences overall community activity.

  • Sentiment fluctuations indicate potential market risks.

  • Events trigger surges in discussion热度 of related tokens.

This layer helps users understand the business logic behind metrics, clarifying "why metrics are designed this way," and guides subsequent metric selection and combination.

---

2.3 C Layer | Logical Indicator Layer — Logical Indicator System

• Core Objective: Based on the conceptual model, abstract a collection of business-meaningful indicators, each with clear sources, dependencies, and application scenarios.

• Indicator Design Principles:

  • Clearly define which conceptual relationship the indicator originates from.

  • Specify the raw fields and tags the indicator depends on.

  • Identify the specific business problem the indicator serves.

  • Explain how indicators can be combined synergistically.

In this layer, users can find indicator collections and usage guidance for specific business scenarios (e.g., heat monitoring, sentiment analysis).

---

2.4 C′ Layer | Physical Indicator Layer — Data Fields and Table Structures

• Core Objective: Provide concrete database fields, table structures, and interface parameters, serving as the data layer for actual operations and calls by customers.

• Characteristics:

  • Includes specific fields such as community_volume, sentiment_score, event_mention_count, etc.

  • Supports structured output with multiple time windows (daily/hourly/minutely).

  • However, lacks higher-level logic and business interpretation, making it easy for customers to feel lost if viewing fields in isolation.

This layer is the entry point for data calls. Users need to combine explanations from the previous layers to understand field meanings and use the data correctly.

---

2.5 D Layer | Application Layer — Business Scenarios and Strategy Design

• Core Objective: Guide customers on how to apply indicators to practical business scenarios, including quantitative strategy development, market monitoring, token selection models, etc.

• Application Forms:

  • Investment portfolio construction and rotation strategies.

  • Public opinion monitoring and early warning systems.

  • Research reports and market trend analysis.

It is recommended to gradually understand indicators from Layers A-B-C and then effectively apply them in Layer D based on business scenarios, avoiding blindly calling single indicators.

---

3. Data Product Usage Process

1. Define Business Requirements For example: "Monitor the trend of token heat changes" or "Capture extreme fluctuations in community sentiment."

2. Review Layer A (Information Model) Identify relevant dimensions (e.g., token, user, community, event).

3. Refer to Layer B (Conceptual Model) Understand the relationships between these dimensions and the underlying business assumptions.

4. Select Layer C (Logical Indicators) Find indicator collections that meet business needs (e.g., activity metrics, sentiment metrics).

5. Call Layer C′ (Physical Indicators) Retrieve specific field data via APIs or data interfaces.

6. Analyze and Design Strategies in Layer D (Application Layer) Develop quantitative strategies, conduct market monitoring, etc., based on the data.