ELSTAND Intelligence

ELSTAND Intelligence adalah ekosistem market-intelligence untuk crypto yang mengubah data makro, market, order flow, on-chain, dan berita menjadi evidence, reasoning, dan konteks keputusan yang bisa ditelusuri — bukan sekadar chart atau skor tanpa alasan di baliknya.

ELVOID adalah decision-intelligence layer di dalam ELSTAND — bagian yang mengubah evidence menjadi keputusan trading yang graded dan risk-aware. ELVOID bukan keseluruhan produk; ia adalah reasoning core dari platform yang juga menangani agregasi data, paper & live trading, membership, dan lapisan wallet/token on-chain (BSC Testnet).

Masalah utamanya bukan kekurangan data — justru sebaliknya.

Rantai kegagalan ini yang coba dipotong ELSTAND — bukan dengan mengejar signal accuracy setinggi mungkin, tapi dengan membuat setiap langkah (evidence → reasoning → decision → outcome → evaluation) terstruktur dan bisa ditelusuri balik ke sumbernya.

Ini adalah Intelligence Loop ELSTAND — satu siklus tertutup, bukan pipeline satu arah. Outcome dari sebuah keputusan mengalir balik lewat evaluation menjadi input untuk reasoning berikutnya (lihat Learning Loop).

• Data → Evidence — data mentah dinormalisasi, ditag sumbernya, dengan fallback jujur kalau sumber tidak tersedia (weight 0, bukan nilai dikarang).
• Evidence → Intelligence — evidence disilangkan lintas sumber & timeframe untuk mencari confluence dan mendeteksi conflict.
• Intelligence → Reasoning — Oracle dan Cognitive Layer ELVOID mengubah intelligence jadi pembacaan graded yang bisa dijelaskan.
• Reasoning → Decision — side, grade, confidence, risk plan — satu keputusan kanonik, bisa ditelusuri balik ke evidence yang membentuknya.
• Decision → Outcome → Evaluation → Learning — apa yang benar-benar terjadi dinilai objektif, lalu dikembalikan sebagai konteks untuk reasoning masa depan.

Komponen yang benar-benar ada di repository, masing-masing menyumbang evidence ke ELVOID:

ELVOID tidak punya akses langsung ke user, wallet, atau membership — semua itu domain ELSTAND. ELVOID hanya menerima evidence yang sudah dinormalisasi dan mengembalikan satu OracleAssessment per permintaan. Batas ini konsisten di seluruh kode: modul Oracle/Cognitive tidak pernah mengimpor logic trading/wallet, dan sebaliknya.

Tiga project Supabase yang terpisah

Arsitektur data dipisah jadi tiga project Supabase independen, masing-masing dengan env var kredensialnya sendiri — bukan satu database besar yang dibagi-bagi secara logis:

Alasan pemisahan: masing-masing project bisa di-scale dan direset secara independen. Learning DB secara eksplisit tidak punya foreign key SQL ke Main DB — source_signal_id hanyalah referensi logis ke ai_signals.id, karena foreign key lintas-project memang tidak mungkin di Postgres/Supabase.

Oracle adalah deterministic pipeline bertahap, bukan satu panggilan LLM. Setiap tahap adalah modul terpisah di lib/ai/oracle/, dan sebagian besar secara eksplisit didokumentasikan sebagai PURE / READ-ONLY — tidak fetch baru, tidak scoring baru, tidak mengubah keputusan yang sudah dibuat tahap sebelumnya.

Otoritas tunggal

gradeConfluence() (grading.ts) adalah satu-satunya sumber kebenaran untuk side/grade/confidence/riskStatus. Contradiction, Scenario, dan Arbitration semuanya membaca hasil ini dan menambah konteks — tidak satu pun boleh menghitung ulang atau menimpanya. Ini prinsip arsitektural yang ditegakkan di komentar kode setiap modul, bukan konvensi yang tidak tertulis.

Grade final: NO_TRADE | B+ | A | A+. A+ membutuhkan dominant score ≥ 35 dan minimal 3 cluster evidence independen — dan otomatis diturunkan (ceiling) kalau risk plan tidak tersedia (S/R protective level tidak ditemukan dari histori candle).

Endpoint: GET /api/elvoid-pro/oracle untuk satu symbol/timeframe, GET /api/elvoid-pro/insights untuk insight tambahan.

Evidence & Confluence

• Setiap angka pada satu evidence factor berasal dari sesuatu yang benar-benar terukur di OracleContext — tidak ada bobot hardcode karena "sinyal seharusnya ada".
• Sumber yang tidak tersedia (quality: "unavailable") selalu diberi weight 0 — tidak pernah diperlakukan sebagai vote netral atau default ke satu sisi.
• Data proxy (mis. Liquidity Volume Map, atau Microstructure untuk symbol selain BTC) weight-nya dibatasi PROXY_WEIGHT_CAP = 0.5 — proxy read tidak pernah bisa mengalahkan skor orderbook/data real.
• Confluence dihitung lintas sumber independen — grade A+ butuh minimal 3 cluster, bukan satu sinyal kuat sendirian.

Contradiction (Conflict)

Contradiction Classifier (Phase 7.6) adalah lapisan reklasifikasi, bukan detector baru — setiap entri di laporannya menelusuri balik ke deskripsi yang sudah dihasilkan modul lain (confluence.contradictions, mtf.ts, scenario.primary.opposingEvidence). Setiap kontradiksi ditandai genuineness-nya:

Risk Plan

Risk plan (entry/SL/TP/R:R) memakai metodologi yang sama dengan AI Signal biasa — SL dari protective S/R terdekat + buffer ATR, TP dari opposing S/R terdekat atau fallback R-multiple tetap — dihitung dari candle history nyata. Kalau histori candle tidak cukup untuk menemukan level protective sama sekali, risk plan mengembalikan null dan grading otomatis menandai riskStatus: "unavailable", menolak grade A+.

ELVOID Cognitive Layer (Phase 8.0.x) melakukan observation → hypothesis → conflict resolution di atas output Oracle yang sudah final.

• Observation (8.0.1) — strictly downstream/read-only: tidak pernah memutasi input, tidak pernah menghitung ulang hasil Phase 2-7.x, tidak melakukan network/database/LLM call apa pun. Input yang sama menghasilkan output yang sama persis (kecuali timestamp).
• Hypothesis Engine (8.0.3) — thin reframing layer di atas Scenario/Contradiction/Arbitration yang sudah dihitung; tidak pernah menurunkan ulang supporting/ opposing evidence atau confidence sendiri. Bahkan tidak mengimpor OracleAssessment secara langsung.
• Conflict Resolution (8.0.4) — pure reuse atas contradictions.hasUnresolvedGenuineContradiction dan arbitration.alignment; tidak pernah memindai ulang evidence mentah atau membuat sistem confidence keduanya.

Kalau sebuah sumber evidence hilang, Cognitive Layer melaporkan state degraded/unavailable apa adanya — tidak pernah mengarang untuk menutupi celah data.

Decision Traceability (Phase 8.2.1) saat ini adalah infrastruktur murni — bentuk tabel dan fungsi persist, mengikuti batas “capture only, decide nothing” yang sama seperti Phase 8.1.0. Fase ini belum memperkenalkan logic autonomous decision, wiring eksekusi, route, atau cron sendiri.

Orchestrator (Phase 8.2.9) menjalankan siklus Oracle → Cognitive → Decision per symbol watchlist tanpa aksi user, dipicu Vercel cron + heartbeat GitHub Actions setiap 15 menit. Orkestrator ini tidak menghitung apa pun sendiri — setiap fungsi scoring/grading/qualification/decision yang dipanggilnya adalah modul Phase 7/8.0-8.2.8 yang sudah ada dan tidak diubah.

• Read-only status: GET /api/elvoid-pro/autonomous/status (snapshot terbaru), GET /api/elvoid-pro/autonomous/snapshots (histori).
• Execution: POST /api/elvoid-pro/autonomous/tick (satu siklus), POST /api/elvoid-pro/execute-signal (eksekusi sinyal jadi order).

Decision Evaluation Engine (Phase 8.1.1) adalah fungsi pure & deterministic — nol call database/network/LLM/fetch, nol pembangkitan timestamp sendiri, nol randomness. Modulnya bahkan tidak mengimpor apa pun dari lib/ai/oracle/*, lib/ai/cognitive/*, lib/elvoid/*, atau modul eksekusi trading manapun — hanya bergantung pada satu DecisionExperienceRecord yang sudah dibekukan.

IMPLEMENTED + RUNTIME EVIDENCE Seluruh rantai ini di-sequence oleh lib/ai/autonomousRuntime/learningRefresh.ts dalam urutan tetap: recomputeFailurePatterns() → recomputeAdaptiveConstraints() → recomputeConstraintValidations(), dijaga lock yang sama dengan batch trading. Tidak ada logic deteksi/generation/validasi baru di file ini — ia hanya memanggil tiga fungsi yang sudah ada, berurutan. Kegagalan di satu langkah menghentikan run tanpa menghapus snapshot sukses sebelumnya.

• Failure Pattern Detection — melaporkan frequency observation murni: menghitung berapa kali satu evidence tag muncul bersamaan dengan evaluasi outcome negatif, untuk satu source, di lebih dari satu hari kalender. Minimal MIN_OCCURRENCE_COUNT = 5 kejadian sebelum sebuah pattern dianggap kandidat. Tidak pernah menyatakan kausalitas.
• Adaptive Constraint — dibangun dari kandidat failure pattern yang sudah lolos ambang di atas; tidak pernah menuliskan ulang atau melonggarkan MIN_OCCURRENCE_COUNT/aturan spread temporal. Constraint bersifat advisory (menaikkan kehati-hatian) — tidak ada jalur yang langsung memblokir eksekusi otonom dari constraint ini.
• Decision Memory Retrieval — retrieveDecisionMemory() adalah fungsi pure (nol DB/network/LLM/randomness), dipanggil live setiap cycle di orchestrator sebelum tahap qualification/decision. Sinyal memory negatif membuat status keputusan CONFLICTED, yang langsung berujung REJECT — tidak pernah menguatkan EXECUTE, selalu fail-safe ke arah WAIT/REJECT. Retrieval ini dan klasifikasi lifecycle pembelajaran (dipanggil setiap cycle) berstatus IMPLEMENTED + RUNTIME EVIDENCE — bukti runtime diamati di dashboard AI Performance (dilaporkan; tidak tersimpan di repository). Yang masih EXPERIMENTAL adalah rantai self-improving di luar learning loop ini — lihat Controlled Self-Evolution.

IMPLEMENTEDPARTIALLY VERIFIED Komponen 8.6.1–8.6.6 sudah ada di source dan diuji fixture offline. Secara end-to-end fase ini EXPERIMENTAL: satu siklus evolusi penuh dalam satu runtime kontinu belum terbukti. Output 8.6.1–8.6.6 berupa catatan dan record, bukan kode — fase ini tidak mengubah keputusan trading hari ini.

8.6.7 — Controlled Self-Improvement / Self-Coding / Self-Evolution

• Batasan historis. Sebelum commit 7e12508 (2026-09-28), merge + deploy dapat terjadi tepat setelah code generation. Gate CI, otorisasi manusia kedua, dan trigger database diperketat setelah itu; halaman ini menjelaskan model saat ini, bukan pipeline awal.
• Label “Phase 9”. Identifier phase9, scripts/phase9, elvoid/phase9/* dan workflow phase9-* adalah label implementasi historis untuk 8.6.7. Tidak ada Phase 9 di roadmap; identifier tidak diubah.
• Cakupan patch. Template proposal saat ini hanya menyebut empat file sumber; hanya dua kategori gap yang menghasilkan scope patch yang tidak masuk denylist.
• Verifikasi. Fixture offline mencakup approval (125 PASS), artifact (21), coding (11), dan git/pipeline (12); fixture jalur otorisasi/CI-gate BLOCKED offline (butuh js-yaml). Verifikasi produksi sebuah evolusi NOT VERIFIED; E2E evolusi penuh belum terbukti.

Detail teknis: docs/ELVOID_COGNITIVE_LAYER.md · roadmap & crosswalk: CHANGES.md.

Hierarki data ekonomi: Alpha Vantage = sumber primer; FRED, ForexFactory, dan sumber lain = pendukung yang boleh memperkaya atau mengonfirmasi, tidak pernah menggantikan atau mengungguli data primer. Pembacaan primer yang hilang, basi, atau tidak berurutan membuat indikator itu UNAVAILABLE (fail-closed).

Detail penuh sudah dibahas di System Architecture & Data Flow. Ringkasan tabel penting:

RLS (Row Level Security) diaktifkan pada seluruh tabel sensitif dengan nol public policy — semua akses lewat service-role key sisi server. Pola ini konsisten di Main DB maupun Learning DB.

Method dan path dikutip langsung dari handler route (app/api/**/route.ts). Schema request/response detail di luar tabel ini: Belum dapat diverifikasi dari implementasi saat ini.

Seluruh integrasi Binance hidup di lib/binance/ — terpisah dari Oracle/Cognitive Layer secara arsitektural (Oracle tidak pernah mengeksekusi order sendiri; eksekusi lewat lib/elvoid/paperTrader.ts atau modul di bawah ini).

Keamanan order: setiap order punya client order ID unik, cooldown singkat mencegah double-submit, dan lock in-process per symbol (orderGuard.ts).

ELSTAND memakai BNB Smart Chain Testnet (chainId 97) untuk ekonomi token dan gating membership on-chain.

Address di atas dikutip verbatim dari CONTRACTS.md pada repository. Belum ada deployment mainnet — status mainnet: ROADMAP.

• IMPLEMENTED Autentikasi Supabase Auth (Google OAuth), ditegakkan di middleware.ts untuk seluruh route terproteksi — request tanpa autentikasi diarahkan ke /login.
• IMPLEMENTED Row Level Security aktif di tabel sensitif, nol public policy — akses butuh service role key sisi server.
• IMPLEMENTED Exchange API key: env var server-only secara default, atau tersimpan di database terenkripsi AES-256-GCM (ENCRYPTION_KEY, server-only).
• IMPLEMENTED Keamanan order: client order ID unik, cooldown double-submit, lock in-process per symbol.
• DESIGN PRINCIPLE No fabricated data — diterapkan konsisten dari Oracle sampai Binance client: sumber gagal → fallback jujur, bukan nilai dikarang.
• DESIGN PRINCIPLE Fail-safe over fail-strong — lock/memory/evidence yang tidak bisa diverifikasi selalu diarahkan ke jalur paling aman (lihat bagian selanjutnya), bukan diasumsikan aman.

Prinsip konsisten di seluruh codebase: kalau sesuatu tidak bisa diverifikasi, sistem jujur soal itu — bukan mengarang nilai pengganti. Beberapa contoh konkret dari kode aktual:

• No fabricated data
• Evidence-first reasoning
• Traceability
• Risk-aware decision
• Explicit uncertainty
• Separation of concerns
• Deterministic decision pipeline
• Satu otoritas keputusan (gradeConfluence)
• LLM sebagai reasoning/narrative layer
• Pure/read-only sebagai default untuk lapisan downstream
• Fail-safe, bukan fail-strong
• Controlled learning, bukan self-modification bebas
• Failure isolation antar-langkah
• Human approval untuk evolusi high-risk

• IMPLEMENTED kode ada dan terjangkau dari jalur runtime atau dapat dipanggil — tidak menyatakan kebenaran.
• IMPLEMENTED + RUNTIME EVIDENCE implemented, dan bukti runtime diamati di dashboard AI Performance (dilaporkan pemilik; tidak tersimpan di repository) — sengaja lebih lemah dari VERIFIED.
• PARTIALLY VERIFIED sebagian perilaku terbukti dari bukti yang dapat direproduksi (umumnya fixture offline).
• EXPERIMENTAL implemented, tetapi E2E dalam satu runtime kontinu belum terbukti.
• ROADMAP konsep/rencana, belum ada kode yang memadai.
• BLOCKED pemeriksaan tidak dapat dijalankan (dependency tidak tersedia offline) — bukan pass dan bukan fail.
• NOT VERIFIED belum ada bukti. VERIFIED hanya bila bukti dapat direproduksi dari repository.

Fixture offline: 66 file · 61 bersih · 0 FAIL · 1.488 baris PASS · 5 BLOCKED (4 butuh @supabase/supabase-js, 1 butuh js-yaml; termasuk controlled-autonomy-and-economic dan autonomous-runtime). Fixture offline ≠ E2E produksi, dan BLOCKED tidak pernah dihitung sebagai PASS. Detail dan matriks verifikasi ada di deep-dive Cognitive Layer; status mengikuti legenda di CHANGES.md. Sejak sinkronisasi ini, README dan halaman ini memakai status Decision Memory yang sama (lihat Learning Loop).

CHANGES.md pada repository kini adalah dokumentasi roadmap panjang dan riwayat evolusi engineering (crosswalk tiga sistem penamaan, status per fase, appendix UI/UX). Changelog per fase yang lama dipulihkan sebagai rekaman historis.

• → CHANGES.md — roadmap panjang + engineering evolution
• → docs/ELVOID_COGNITIVE_LAYER.md — deep-dive teknis Cognitive Layer, E2E dan verifikasi
• → docs/changelog/ENGINEERING_DELTA_LOG.md — rekaman historis engineering per fase
• → CONTRACTS.md — daftar address contract terdeploy