مصدر البيانات المستخدمة في هذه الدراسة

أثناء اختبار واجهة RadarX العامة سجلنا استجابة فعلية من مسار Top 10 العام. كانت الاستجابة تخص البيئة live وفريم 5m، وتحمل Snapshot رقم 114900.

قيمة bucket_open_time_ms كانت 1787146200000، أي 19 أغسطس 2026 الساعة 13:30 بتوقيت UTC. كما سجلت Snapshot أن عدد الأزواج التي وصلت إلى مرحلة الفحص كان 409 أزواج.

Source of the data used in this case study

During testing of the public RadarX interface, we captured a real response from the public Top 10 endpoint. The response belonged to the live environment and the 5m timeframe and carried snapshot ID 114900.

Its bucket_open_time_ms value was 1787146200000, corresponding to August 19, 2026 at 13:30 UTC. The snapshot also reported that 409 pairs reached the scanning stage.

لقطة سريعة لبيانات Snapshot

Snapshot metadata at a glance

ماذا نعرف عن العنصر الذي ظهر في بداية النتيجة؟

في المقتطف الذي حفظناه من الاستجابة، ظهر أحد عناصر النتيجة بسعر 76.37 وقيمة k_hit تساوي 8. كما كانت أفضل ثلاث إشارات مسجلة له: MACD وVolume وKDJ.

النقطة المهمة هنا هي أن k_hit = 8 لا تعني أن كل الشروط نجحت، ولا تعني أن احتمال الربح يساوي رقمًا معينًا. هي ببساطة تخبرنا أن ثمانية شروط قابلة للحساب كانت في حالة تحقق وفق تلك Snapshot.

What do we know about the item shown at the beginning of the response?

In the stored response excerpt, one result item appeared with a price of 76.37 and a k_hit value of 8. Its recorded top-three signals were MACD, Volume and KDJ.

The important point is that k_hit = 8 does not mean every condition passed and does not represent a fixed probability of profit. It simply records eight matched computable conditions for that snapshot.

لماذا كانت قراءة EMA متحققة؟

المقتطف الفعلي احتوى على تفاصيل شرط EMA، وأظهر أن سعر الإغلاق 76.370000 كان أعلى من عدة متوسطات أسية مستخدمة في هذا الشرط.

هذه الأرقام تفسر لماذا اعتبر شرط EMA متحققًا في تلك اللحظة: الإغلاق كان أعلى من المتوسطات المذكورة. لكنها لا تعني أن السعر سيبقى فوقها لاحقًا، ولا تجعل EMA وحده سببًا كافيًا لاتخاذ قرار.

Why was the EMA condition matched?

The real response excerpt included the EMA rule details and showed that the closing price, 76.370000, was above several exponential moving averages used by that condition.

These values explain why the EMA rule was matched at that time: the close was above the listed averages. They do not imply that price will remain above them later, and EMA alone is not enough to make a financial decision.

لماذا نهتم بالشرط غير المتحقق أيضًا؟

بداية المقتطف التالي لشرط EMA أظهرت أن شرط RSI كان غير متحقق. لا نملك في النسخة المحفوظة تفاصيل RSI الكاملة، لذلك لا نضيف تفسيرًا رقميًا غير موجود في البيانات.

هذه النقطة بحد ذاتها مهمة: RadarX لا يعرض صورة ثنائية من نوع "الزوج جيد" أو "الزوج سيئ". يمكن أن يكون عدد كبير من الشروط متحققًا بينما تبقى شروط أخرى غير متحققة.

Why does an unmatched condition matter too?

The beginning of the next rule after EMA showed that RSI was not matched. The stored excerpt does not contain the complete RSI details, so this case study does not invent a numerical explanation that is not present in the data.

That point is useful by itself: RadarX does not reduce a market reading to “good pair” or “bad pair.” Many conditions can match while other conditions remain unmatched.

ما البيانات التي لم نخترعها؟

النسخة المحفوظة التي استخدمناها لهذه الدراسة لم تحتفظ أمامنا بكل حقول العنصر ضمن المقتطف المتاح. لذلك لم نضع اسم الزوج أو قيمة liquidity_grade أو spread_bps أو volume_mult على أنها حقائق إذا لم تكن موجودة في النص الذي سجلناه.

في RadarX الفعلي يمكن لهذه الحقول أن تكون جزءًا من نتيجة Top 10، لكن الدراسة الجيدة يجب أن تميز بين البيانات التي تم توثيقها فعلًا وبين المعلومات التي نتوقع وجودها في بنية النظام.

Which values did we deliberately avoid inventing?

The stored excerpt used for this case study did not preserve every item field in the portion available to us. We therefore do not present a symbol name, liquidity_grade, spread_bps or volume_mult as facts when those values were not present in the recorded excerpt.

These fields can be part of a real RadarX Top 10 item, but a useful case study should clearly separate values that were actually documented from values that are merely part of the system's data structure.

كيف نعرف أن Snapshot ليست نتيجة ثابتة؟

في اختبار منفصل للـLive Push أبقينا اتصال WebSocket مفتوحًا وانتظرنا نتيجتين متتاليتين على فريم 5m. وصلت أولًا Snapshot تحمل bucket عند 13:55 UTC، ثم وصلت Snapshot جديدة عند 14:00 UTC على الاتصال نفسه.

لا نستنتج من هذا الاختبار أن نفس الأزواج بقيت في القائمة؛ الاختبار يثبت فقط أن Snapshot جديدة تم إنتاجها ودفعها للعميل. ولهذا يجب إعادة قراءة القائمة الجديدة بدل افتراض استمرار حالة Snapshot السابقة.

How do we know a snapshot is not a permanent result?

In a separate Live Push test, we kept a WebSocket connection open and waited for two consecutive 5m results. The first snapshot had a bucket at 13:55 UTC, followed by a new snapshot at 14:00 UTC on the same connection.

This does not prove that the same pairs remained in the list. It proves that a new snapshot was produced and pushed to the client. The new list should therefore be read again rather than assuming that the previous state continued unchanged.

ماذا نتعلم من هذه Snapshot الفعلية؟

What can we learn from this real snapshot?