MindRelay
MindRelay
Күшіне енген күні: 2026 жылғы 6 тамыз | соңғы жаңарту: 2026 жылғы 6 тамыз | нұсқа: 2.0
Жобаның толық ресми атауы — MindRelay. Атау ағылшын тілінің екі сөзінен құралған: Mind (ақыл, сана, ой) және Relay (эстафета, жеткізу, қайта тарату). Бұл құрама атау жобаның негізгі идеясын дәл көрсетеді — ақпарат пен ойды бір орыннан екінші орынға, бір адамнан екінші адамға «эстафета» тәрізді жеткізу, әрі осы процесте оны жай ғана тасымалдамай, өңдеп, байланыстырып, мағынасын байыту. «Relay» сөзі техникалық мағынада да қолданылады (сигналды қабылдап, күшейтіп, қайта жіберетін құрылғы) — бұл MindRelay-дің де дәл сол қызметті атқаратынын білдіреді: ақпаратты қабылдайды, өңдейді (күшейтеді/байытады), қайта жібереді.
MindRelay — жасанды интеллект технологияларына негізделген интеллектуалдық ақпараттық жүйе. Бұл анықтаманы үш бөлікке бөліп қарастыруға болады: «Ақпараттық жүйе» дегені — жүйенің негізгі қызметі ақпаратпен жұмыс істеу: оны қабылдау, сақтау, өңдеу, беру; «Интеллектуалдық» дегені — бұл жұмыс механикалық түрде емес, жасанды интеллект арқылы, мағынаны түсінуге негізделген түрде жүзеге асырылады; жүйе бір ғана бағдарлама емес, бірнеше өзара байланысқан құрамдас бөліктен (бот ядросы, басқару панелі, дерек қоймасы, сыртқы интеграциялар) тұратын біртұтас экожүйе.
Жүйенің «жүзі» әрі Пайдаланушымен тікелей сөйлесетін құрамдас бөлігі — N.I.R.A. (Neural Intelligent Relay Assistant). Атаудың толық ашылуы:
| Әріп | Ағылшынша | Мағынасы |
|---|---|---|
| N | Neural | нейрондық — жасанды интеллект/машиналық оқыту технологиясына негізделген |
| I | Intelligent | интеллектуалды — жай сценарий бойынша емес, түсініп жауап беретін |
| R | Relay | эстафета — MindRelay атауымен үндес, ақпаратты жеткізу қызметі |
| A | Assistant | көмекші — түпкі рөлі, адамға қызмет көрсету |
N.I.R.A. мен MindRelay арасындағы қатынасты былай түсіндіруге болады: MindRelay — бүкіл жүйенің атауы (платформа), ал N.I.R.A. — сол платформаның Пайдаланушыға көрінетін, сөйлесетін бөлігі. Дашборд, дерек қоймасы, сыртқы интеграциялар сияқты қалған бөліктер тікелей Пайдаланушыға көрінбейді — олар N.I.R.A. арқылы жанама түрде қызмет етеді.
MindRelay қазіргі уақытта белсенді дамуда тұрған жоба, әрі сонымен қатар өндірістік (production) режимде нақты жұмыс істейді — яғни бұл тек прототип немесе демо-нұсқа емес, нақты Пайдаланушылармен нақты уақытта хабарласатын, нақты деректерді сақтайтын, күнделікті пайдаланылатын жүйе. Бұл екі сипат («белсенді дамуда» және «өндірістік режимде») бір-біріне қайшы емес — жоба жұмыс істеп тұрған күйінде де үздіксіз жаңартылып, толықтырылып отырады (толығырақ — 11-бөлім, «Жобаның тарихы»).
Жобаның авторы, идея иесі және жалғыз әзірлеушісі — Қалқөз Ернат. MindRelay команда немесе ұйым жасаған жоба емес — бастапқы идеядан бастап қазіргі күнге дейінгі барлық сәулет, код және мазмұн бір адамның қолымен жасалған (толығырақ — 15-бөлім, «Автор және байланыс»).
MindRelay Пайдаланушылармен байланысу үшін екі негізгі мессенджер платформасын қолданады: WhatsApp және Telegram. Бұл екеуінің таңдалу себебі — жобаның бастапқы идеясы кезінде-ақ (6 маусым 2026, толығырақ 11-бөлімде) осы екі арнаның ең көп қолданылатын, әрі автордың өз қажеттілігіне сай келетін арналар болғаны. «Бастапқы» деген сөз бұл тізімнің шектеулі екенін білдірмейді — 13-бөлімде («Болашақ жоспарлар») көрсетілгендей, жүйе басқа арналарға да кеңеюі мүмкін.
MindRelay жобасының түпкі мақсаты — бір сөйлеммен айтқанда: жай хабарлама алмасу құралы болудан бас тартып, ақпаратты жинаушы, оның ішінен байланыстарды анықтаушы, содан білім қалыптастырушы және уақыт өте келе тұтас интеллектуалды жүйеге айналушы платформа болу.
Бұл тұжырымда төрт кезеңді байқауға болады, олар бір-бірінен туындайды: Жинау → Байланыстыру → Білім қалыптастыру → Тұтас интеллектуалды жүйе.
Әрбір кезең алдыңғысының нәтижесіне сүйенеді — жиналмаған ақпаратты байланыстыру мүмкін емес, байланыстырылмаған ақпараттан білім шығару мүмкін емес, ал жинақталған білімсіз тұтас интеллектуалды жүйе болуы мүмкін емес. Осы себепті мақсатты алты нақты бағытқа бөліп қарастырамыз — олардың әрқайсысы осы тізбектің бір буыны.
Бұл — тізбектің бастапқы, ең негізгі буыны. MindRelay жеке чаттардан, топтық чаттардан, дауыстық хабарламалардан және суреттерден мағыналы деректерді бөліп алады. Маңызды нәрсе — жинау процесі іріктеу болып табылады, «бәрін сақтау» емес: жүйе кездейсоқ, мәні жоқ хабарламаларды мағыналы фактілерден ажыратады (толық техникалық сипаттама — MR-003 құжатының 1–2-бөлімдері, ал философиялық негіздеме — MR-006 құжатының 6-бөлімі, «Профильге енгізілмейтін ақпараттар»).
Жиналған ақпарат бір-бірінен оқшауланған жазба ретінде қалмайды — жүйе олардың арасында мағыналы қатынас іздейді: белгілі бір адам мен жоба арасындағы байланыс, тақырып пен тармақша тақырып арасындағы байланыс, немесе екі түрлі диалог арасындағы жасырын ұқсастық. Мысалы, «Ернат» пен «MindRelay» жобасы арасындағы байланыс, немесе «Робототехника» мен «Arduino» тақырыптарының өзара байланыстылығы (толық түсіндірме — MR-006 құжатының 7-бөлімі, «Байланыстарды қалыптастыру»).
Жинақталған және байланыстырылған ақпарат негізінде жүйе жалпыланған қорытындылар мен білім элементтерін қалыптастырады. Бұл — жиналған деректерден сапалық секіріспен өтетін кезең: жеке фактілер («Ернат Arduino қолданады», «Х жиі сұралды») енді нақты бір диалогтан немесе Пайдаланушыдан ажыратылған, дербес құндылыққа ие жалпы білімге айналады (толық түсіндірме — MR-006 құжатының 9-бөлімі, «Білім элементтерін қалыптастыру»).
Білім қоры тек сақталу үшін емес, жаңа идеялар, ұсыныстар немесе шешім жолдарын қалыптастыру үшін де пайдаланылады. Бұл, атап айтқанда, ұқсас сұрақтар мен жағдайлар арасындағы заңдылықтарды анықтау арқылы жүзеге асады — жүйе бұрын кездескен ұқсас мәселелерді еске алып, соған сүйене отырып жаңа ұсыныс жасай алады.
MindRelay белгілі бір Пайдаланушының немесе тақырыптың алдыңғы контекстін сақтайды, бұл қайталама сұрақтарды қайта түсіндірудің қажетсіздігін қамтамасыз етеді. Бұл функция Пайдаланушы тәжірибесі тұрғысынан ерекше маңызды — әр жолы жаңадан бастаудың орнына, N.I.R.A. Пайдаланушыны «есінде сақтайды» (толық техникалық сипаттама — MR-006 құжатының 4-бөлімі, «Профильдеу ұғымы»).
Осы бөлімде аталған алдыңғы бес мақсаттың барлығының түпкі нәтижесі — N.I.R.A. арқылы уақтылы, мәнмәтінге сай жауап беру. Бұл мақсат өз алдына соңғы, көрінетін нәтиже болып табылады: Пайдаланушы үшін бүкіл күрделі ішкі процесс (жинау, байланыстыру, білім қалыптастыру) сырттан бір ғана нәрсе түрінде көрінеді — дәл әрі пайдалы жауап.
Осы алты бағыт жеке-дара, бір-бірінен тәуелсіз міндеттер емес — олар бірізді процестің сатылары ретінде жұмыс істейді. Бұл принцип MR-006 құжатының 2.8-тармағында да расталған: «жинау, байланыстыру, қалыптастыру, идея жасау, контекст сақтау, сапа арттыру — бір-бірінен бөлек емес, бірізді процестің сатылары».
Мұның практикалық маңызы мынада: MindRelay-дің кез келген жаңа функциясын немесе өзгерісін бағалағанда, ол осы алты бағыттың қайсысына қызмет ететінін анықтау арқылы жобаның негізгі мақсатына сай келе ме, жоқ па — соны тексеруге болады.
2-бөлімде сипатталған мақсат — жобаның нені істейтінін көрсетсе, миссия — неге істейтінін, қандай құндылыққа қызмет ететінін білдіреді. Мақсат операциялық (не істеу керек), ал миссия — идеологиялық (не үшін істеу керек) сипатта болады. MindRelay үшін миссия екі деңгейде тұжырымдалған: қысқа, есте қаларлық нұсқа және оны толық ашатын кеңейтілген нұсқа.
«Ақпаратты байланыстырып, білімге айналдыру»
Бұл тұжырым үш сөзден тұрса да, жобаның бүкіл мәнін қамтиды: «Ақпаратты» — шикізат, бастапқы материал (диалогтар, хабарламалар, фактілер); «байланыстырып» — процестің өзі, өзгертуші әрекет (2-бөлімдегі «байланыстыру» кезеңі); «білімге айналдыру» — түпкі нәтиже, шикізаттың жаңа, жоғары деңгейдегі формаға өтуі.
Бұл қысқа нұсқа — жобаны бір сөйлеммен таныстыру керек болған жағдайда (мысалы, серіктеске алғаш айтқанда) қолданылатын «эталон» тұжырым.
«MindRelay — адамның цифрлық өміріндегі ақпараттарды жинап, олардың арасындағы байланыстарды тауып, құрылымдап және уақыт өте келе интеллектуалды білім жүйесіне айналдыратын платформа.»
Бұл кеңейтілген нұсқаны бөлшектеп қарастырайық:
| Тұжырым бөлігі | Мағынасы |
|---|---|
| «адамның цифрлық өміріндегі ақпараттар» | Дереккөз — Пайдаланушының нақты өмірі емес, оның цифрлық іздері: хабарламалар, диалогтар, медиа |
| «жинап» | 2.2.1-тармақтағы «Ақпарат жинау» бағытына сәйкес |
| «байланыстарды тауып, құрылымдап» | 2.2.2-тармақтағы «Ақпаратты байланыстыру» бағытына сәйкес |
| «уақыт өте келе» | Бұл — бір реттік әрекет емес, үздіксіз, кумулятивті процесс екенін көрсетеді |
| «интеллектуалды білім жүйесіне айналдыратын» | Түпкі нәтиже — жай дерекқор емес, өзі ойлай алатын, дамитын жүйе |
«Уақыт өте келе» деген тіркес бұл жерде ерекше маңызды — ол миссияның статикалық емес, динамикалық сипатын білдіреді. MindRelay бір рет жасалып, содан кейін тұрақты күйде қалатын өнім емес, керісінше, әр диалог сайын, әр жаңа Пайдаланушы сайын өзгеріп, дамып отыратын жүйе (бұл идея кейінірек 12-бөлімде, «Қазіргі жағдай», және MR-006 құжатының 15-бөлімінде, «Білім қорының үздіксіз дамуы», тереңірек ашылады).
Бұл екі нұсқа бір-бірін алмастырмайды, әрқайсысының өз орны бар: Қысқа тұжырым — жарнамалық материалдарда, бір беттік таныстыруларда, ауызша сипаттауда; Толық тұжырым — ресми құжаттарда (дәл осы паспортта), инвесторға немесе серіктеске тереңірек түсіндіру қажет болғанда, жобаның негізгі бағдары ретінде талқыланғанда.
Екі тұжырым да 4-бөлімде («Көрініс / Vision») сипатталатын ұзақ мерзімді бағыттың негізі болып табылады — миссия «қазір не істеп жатырмыз» десе, көрінісі «болашақта не болады» дегенге жауап береді.
Кез келген адам MindRelay-ді бүгін ашып көрсе, сыртқы тұрғыда оны қарапайым жеке AI-көмекші деп қабылдауы мүмкін — WhatsApp пен Telegram арқылы хабарласатын, сұрақтарға жауап беретін, кейбір ақпаратты есте сақтайтын бот. Бұл қабылдау қате емес, бірақ толық емес. Себебі жобаны жобалау кезінде-ақ, яғни әлі бірінші функциялар да жазылмай тұрып (6 маусым 2026, 11.1-тармақты қараңыз), оның ұзақ мерзімді даму траекториясы алдын ала ескерілген болатын.
Бұл — көрініс (vision) бөлімінің неге маңызды екенінің басты себебі: ол қазіргі, көзге көрінетін жай функционалдың артында тұрған түпкі бағдарды ашады. Көріністі білмей MindRelay-ді бағалау — ағаштың қазіргі көлемін көріп, оның қандай биіктікке дейін өсе алатынын елемеумен бірдей.
Болашақта жүйенің үш деңгейге дейін кеңеюі көзделген. Бұл деңгейлер бір-бірін алмастырмайды — керісінше, әрқайсысы алдыңғысының үстіне қаланатын, оны қамтитын кеңірек тұжырымдама:
Бірінші деңгей — MindRelay жай ассистент емес, Пайдаланушының барлық білімін басқаратын операциялық жүйе дәрежесіне жетуі. «Операциялық жүйе» терминінің қолданылуы кездейсоқ емес: компьютердің операциялық жүйесі қалай барлық қосымшалар мен процестерді үйлестіріп басқарса, дәл солай MindRelay да Пайдаланушының барлық ақпараттық ағындарын (әр түрлі мессенджерлер, тақырыптар, жобалар) бір орталықтан басқаратын негізге айналуы тиіс. Бұл деңгейде MindRelay бір қосымша емес, барлық басқа құралдар үстінде тұрған платформа болады.
Екінші деңгей — терминологиялық екпінді «операциялық жүйеден» «жадыға» ауыстырады. Бұл деңгейде MindRelay адамның биологиялық жадысының цифрлық жалғасы ретінде қызмет етеді: адам ұмытып қалатын, бірақ маңызды болған әрбір факт, әрбір байланыс, әрбір идея жүйеде сақталып, керек кезінде қайта шығарылады. MR-006 құжатының 4.3-тармағында сипатталған «N.I.R.A. Пайдаланушының бұрын не айтқанын... есте сақтайды» деген қазіргі функция — дәл осы болашақ деңгейдің ең бастапқы, қарапайым көрінісі. Ерекшелігі — қазіргі жады бір Пайдаланушы-N.I.R.A. диалогымен шектелсе, «Цифрлық жады жүйесі» деңгейінде бұл адамның бүкіл цифрлық өмірін қамтитын тұтас жады болуы тиіс.
Үшінші, ең жоғары деңгей — «Екінші ми» тұжырымдамасы. Бұл термин білім менеджменті саласында кеңінен қолданылатын идеяны білдіреді: адамның өз миы шектеулі есте сақтау және өңдеу қабілетіне ие болғандықтан, сыртқы, цифрлық «екінші ми» құру арқылы бұл шектеуді жеңу. Бірақ MindRelay контексінде бұл жай пассивті сақтау орны емес — ол белсенді, ойлай алатын серіктес: жаңа байланыстарды өзі анықтайды (MR-006 құжатының 8-бөлімі, «Білім графтары»), идеялар ұсынады (2.2.4-тармақ), тіпті өзін-өзі жетілдіреді (MR-005 құжатының 3-бөлімі, «Деректерді сақтау мақсаттары»).
Бұл үш деңгейді сатылы баспалдақ ретінде елестетуге болады: төменде — қазіргі жеке AI-көмекші (WhatsApp/Telegram бот), одан жоғары — Жеке білім операциялық жүйесі (бір ассистенттен барлық ақпаратты үйлестіретін негізге айналу), одан жоғары — Цифрлық жады жүйесі (жеке диалогтан бүкіл цифрлық өмірге кеңею), ал ең жоғарыда — «Екінші ми» платформасы (белсенді, ойлай алатын серіктеске айналу).
Әрбір жоғарғы деңгей төменгісінің функционалдық негізінде тұрады, бірақ оны сапалық тұрғыда кеңейтеді. Бұл — жобаның неге «үздіксіз даму» қағидатын басты орынға қоятынының түсіндірмесі (8-бөлім, «Негізгі қағидалар»): даму тоқтаса, жоба бірінші деңгейде — қарапайым ботта — қалып қояды.
Осы болашақ бағытты ескере отырып, жобаның ресми анықтамасын келесі түрде тұжырымдауға болады:
«MindRelay — адамдар, идеялар, жобалар және білім арасындағы байланыстарды сақтап, ақпаратты ұзақ мерзімді интеллектуалды жадыға айналдыратын жүйе.»
Бұл анықтаманы 3-бөлімдегі («Миссия») толық тұжырыммен салыстыру пайдалы: миссия процеске («жинап... айналдыратын») екпін берсе, көрініс — нәтижеге («сақтап... жады»); миссия қазіргі әрекетті білдірсе, көрініс — ұзақ мерзімді мақсатты; миссияда негізгі сөз «Платформа» болса, көріністе — «Жүйе».
Бұл екеуінің арасындағы айырмашылық түбегейлі емес — миссия «қазір не істеп жатырмыз» дегенге, ал көрінісі «ақыр соңында не болады» дегенге жауап береді. Екеуі бір бағыттың екі уақыттық проекциясы.
Бұл бөлімнің тек декларативті емес, практикалық маңызы бар: 13-бөлімде («Болашақ жоспарлар») көрсетілген нақты даму бағыттары (мобильді нұсқа, веб-панельдің кеңеюі, білім графының өсуі) — барлығы осы үш деңгейлік траекторияның белгілі бір нүктелеріне сәйкес келетін қадамдар. Яғни көрініс — абстрактілі армандар тізімі емес, жобаның нақты даму жоспарын бағыттайтын компас.
MindRelay-ді жобалау кезінде ең бірінші шешілуі тиіс сұрақтардың бірі — жүйені бір тұтас, монолитті бағдарлама ретінде жазу керек пе, әлде бірнеше бөлек бөлікке бөлу керек пе деген мәселе болды. Таңдау екіншісіне түсті: MindRelay микросервистік құрылым принципіне жақын, дегенмен таза микросервистік архитектура емес — бұл аралық шешім. Толық микросервистік жүйеде әрбір компонент өз алдына толық тәуелсіз, тіпті бөлек серверде орналасуы мүмкін. MindRelay-де компоненттер бір-бірімен HTTP/API және ортақ файл жүйесі арқылы байланысады, бірақ олар негізінен бір машинада, тығыз үйлестірілген түрде жұмыс істейді.
Мұндай аралық тәсілдің таңдалу себебі практикалық: жалғыз әзірлеуші (1.5-тармақ) үшін толық микросервистік архитектураны басқару — артық ұйымдастырушылық жүк, ал бір ғана монолитті файлға бәрін жазу — кодтың тым қиын оқылатын, қауіпті түрде өзгертілетін жағдайға жетуіне алып келер еді (нақты дәлел — main.py файлының өзі 8 500 жолдан асып кетті, толығырақ 11.5-тармақта). Сондықтан аралық жол таңдалды: функционалдық жауапкершілік бойынша бөлу, бірақ физикалық орналасу бойынша бөлмеу.
Бұл таңдаудың үш нақты артықшылығы бар: Тәуелсіз даму — бот ядросындағы өзгеріс дашбордты бұзбайды, және керісінше; Ақаулықтың оқшаулануы — WhatsApp көпірінде ақау болса, Telegram арқылы байланыс жалғасады (бот ядросы екеуін де дербес басқарады); Технологиялық еркіндік — әрбір компонент өзіне ең қолайлы технологияны қолдана алады (5.4-тармақты қараңыз, неге WhatsApp көпірі Python емес, Node.js-те жазылған).
Бұл — жүйенің орталық, үйлестіруші компоненті. Python тілінде, Flask веб-фреймворкі негізінде жазылған, 5000-портта жұмыс істейді. Оның жауапкершілігіне мыналар кіреді: WhatsApp пен Telegram-нан келетін барлық хабарламаларды қабылдау; хабарламаны талдап, оның тілін анықтау, санатын (сұрақ па, өтініш пе, шағым ба) белгілеу; диалог логикасын толық басқару — амандасу, негізгі әңгіме, қоштасу сценарийлерінің барлығы осы жерде; core/ пакетіндегі модульдерді (5.2.2-тармақты қараңыз) шақырып, оларды бір-бірімен үйлестіру; AI провайдерлерімен (OpenAI, Groq, Google) тікелей байланыс орнату (толығырақ — 7-бөлім); барлық нәтижені obsidian/writer.py арқылы дерек қоймасына жазу.
Бұл файлдың қазіргі көлемі — шамамен 8 500 жол (441 КБ), ол жобаның ең үлкен әрі ең маңызды жалғыз файлы. Мұндай көлем өзі бір мәселе тудырады — ол жайлы ескерту 5.6-тармақта берілген.
Егер бот ядросы (main.py) жүйенің «жүрегі» — қан айналымын қамтамасыз етуші орталық — болса, core/ пакеті оның «миы», яғни нақты интеллектуалдық және есептеу логикасы шоғырланған жер. Бұл пакет бірнеше дербес модульден тұрады:
| Модуль | Класс/функция | Жауапкершілігі |
|---|---|---|
| agent.py | MindRelayAgent | Негізгі агент логикасы — N.I.R.A.-ның «шешім қабылдау» орталығы |
| pipeline.py | CognitivePipeline | Когнитивтік өңдеу тізбегі — хабарлама келгеннен жауап шыққанға дейінгі қадамдар реттілігі |
| knowledge_graph.py | — | Білім графының құрылымы мен логикасы (толық түсіндірме — MR-006 құжатының 8-бөлімі) |
| learning.py | LearningSystem | Жүйенің өзін-өзі үйрету механизмі (күнделікті оқу журналы, MR-005 құжатының 3.2-тармағы) |
| rag.py | ObsidianRAG | Retrieval-Augmented Generation — білім қорынан тиісті ақпаратты іздеп табу жүйесі |
| calendar_service.py | GoogleCalendarService | Google Calendar интеграциясының қызметтік қабаты |
| category.py | — | Пайдаланушыларды санатқа бөлу логикасы (MR-006 құжатының 5-бөлімі) |
| scheduler.py | SchedulerService | Жоспарланған тапсырмаларды (мысалы, түнгі өзін-өзі тестілеуді) уақыты келгенде іске қосушы |
| weekly_report.py | — | Апталық қорытынды есептерді қалыптастыру |
Бұл модульдік бөлудің маңызы зор: agent.py мен pipeline.py арасындағы айырмашылықты түсіну үшін — агент «не істеу керек» деген шешім қабылдайтын логика болса, pipeline сол шешімнің нақты қадамдармен (хабарламаны қабылдау → тіл анықтау → контекст жүктеу → AI-ға жіберу → жауапты өңдеу → сақтау) орындалу тәртібін білдіреді.
Бұл пакет екі файлдан тұрады: telegram_bot.py және whatsapp_bot.py. Олардың міндеті — әрбір байланыс арнасына тән ерекшеліктерді (хабарлама форматы, идентификация тәсілі, API шектеулері) бот ядросынан оқшаулау. Бұл бөлудің арқасында, мысалы, WhatsApp-тың LID/нөмір мәселесі сияқты арнаға тән қиындықтар (11.5-тармақты қараңыз) тек осы бір файлда шешіліп, қалған жүйеге әсер етпейді.
writer.py файлындағы ObsidianWriter класы — жүйенің дерек қоймасымен (Obsidian) жалғыз байланыс нүктесі. Бұл маңызды сәулеттік шешім: жүйенің қалған бөліктері файлдарды тікелей жазбайды, керісінше, барлық жазу операциясы осы бір орталықтан өтеді. Мұның артықшылығы — файл құрылымының, атау ережелерінің (MR-006 құжатының файл құрылымы туралы бөлімдерімен үйлесімді) бірізділігін қамтамасыз ету: егер болашақта файл құрылымын өзгерту қажет болса, тек осы бір файлды түзету жеткілікті.
Бот ядросынан мүлдем бөлек Flask қосымшасы, 8080-портта жұмыс істейді. Бөлек болу себебі маңызды: егер басқару панелі бот ядросымен бір процесте жұмыс істесе, дашбордтағы ауыр операция (мысалы, үлкен есеп генерациялау) бот жауабының баяулауына әкелер еді. Бөлек процесс ретінде жұмыс істеу бұл тәуекелді жояды. Бұл файлдың қазіргі көлемі — шамамен 4 600 жол. Толық функционалдық сипаттамасы 6-бөлімде («Технологиялық стек») және Пайдалану шарттарында (MR-002) берілген.
Жалғыз Node.js-те жазылған компонент (себебі — 5.4-тармақта). @whiskeysockets/baileys кітапханасын қолданады, ол WhatsApp Web протоколымен тікелей, ресми емес (WhatsApp Business API арқылы емес) байланыс орнатады. Авторизация QR-код арқылы жүзеге асырылады — Пайдаланушы (яғни осы жағдайда автордың өзі) телефонындағы WhatsApp қосымшасымен QR-кодты сканерлейді, содан кейін сессия сақталып, келесі жолы қайта сканерлеу қажет болмайды (сессия деректері auth_info/ папкасында сақталады).
20-дан астам JSON файлынан тұратын бұл пакет жүйенің «ұзақ мерзімді емес, бірақ маңызды» күйін сақтайды — мысалы, VIP контактілер тізімі, ашық сұраныстардың (zapros) күйі, гейміфикация деректері (квесттер, статистика), баға трендтерінің тарихы, ереже ұсыныстарының күйі, түнгі өзін-өзі тестілеудің соңғы нәтижесі. Бұл файлдар Obsidian дерек қоймасынан ерекшеленеді — Obsidian «мазмұндық» ақпаратты (диалогтар, профильдер, білім) сақтаса, config/ жүйенің «операциялық» күйін сақтайды.
Бұл пакет — жүйенің ішкі жұмысына емес, сыртқа қатынасына арналған компонент: index.html, about.html, documents.html және дәл осы құжат сериясына сәйкес келетін doc-privacy.html, doc-terms.html, doc-retention.html, doc-liability.html, doc-ai-policy.html файлдары. Бұл — MindRelay-дің тек техникалық жүйе ғана емес, сонымен қатар өз Пайдаланушыларына ашық, есеп беретін жоба болуға тырысатынының нақты дәлелі (толығырақ — 8-бөлім, «Негізгі қағидалар», «Ашықтық» қағидаты).
Бір хабарламаның жолын толық қадамдап көрсетейік — Пайдаланушы WhatsApp арқылы хабарлама жіберген сәттен бастап, жауап алғанға дейін:
Қабылдау: хабарлама WhatsApp серверлерінен whatsapp/index.js көпіріне жетеді (Baileys кітапханасы арқылы);
Жіберу: көпір хабарламаны HTTP сұранысы түрінде бот ядросына (main.py, 5000-порт) жібереді;
Алдын ала өңдеу: бот ядросы bots/whatsapp_bot.py арқылы WhatsApp-қа тән форматтауды өңдейді (мысалы, LID/нөмір мәселесі осында шешіледі);
Когнитивтік өңдеу: хабарлама core/pipeline.py-дегі CognitivePipeline-ге беріледі, ол тілді анықтайды, контексті core/rag.py арқылы Obsidian-нан жүктейді, санатты core/category.py арқылы белгілейді;
Шешім қабылдау: core/agent.py-дегі MindRelayAgent не істеу керектігін шешеді — тікелей жауап беру ме, әлде сұраныс (zapros) ретінде ресімдеу керек пе;
AI шақыру: таңдалған әрекетке сәйкес сұраныс AI провайдерлер тізбегіне (7-бөлім) жіберіледі;
Жазу: нәтиже — жаңа факт, жаңартылған профиль, диалог жазбасы — obsidian/writer.py арқылы дерек қоймасына жазылады;
Кері жіберу: қалыптасқан жауап бот ядросынан кері whatsapp/index.js көпіріне, содан кейін WhatsApp серверлері арқылы Пайдаланушыға жетеді.
Осы тізбектің параллель тармағы ретінде, басқару панелі (dashboard/app.py) кез келген сәтте осы процестің нәтижесін — жаңартылған Obsidian файлдарын және config/ күй файлдарын — тікелей оқи алады, себебі ол бөлек процесс ретінде сол ортақ файл жүйесіне қолжетімді.
Оқырманда заңды сұрақ туындауы мүмкін: неге бүкіл жүйе бір тілде жазылмаған? Жауабы — әрбір міндетке сай құрал таңдау қағидатында. WhatsApp-пен тікелей, ресми емес байланыс орнататын ең тұрақты, кеңінен қолданылатын кітапхана — Baileys — JavaScript/Node.js ортасына арналған. Оны Python-ға «қайта жазу» орнына, дайын әрі сыналған шешімді сол өз ортасында пайдаланып, тек оны қалған Python жүйесімен HTTP арқылы жалғастыру таңдалды. Бұл — 5.1-тармақта аталған «технологиялық еркіндік» артықшылығының нақты мысалы.
Бот ядросы мен басқару панелінің екеуі де ортақ бір дерек қоймасын — Obsidian негізіндегі Markdown файлдық жүйені — пайдаланады, дәстүрлі реляциялық дерекқордың (MySQL/PostgreSQL) орнына. Бұл таңдаудың толық негіздемесі мен артықшылықтары 6.3-тармақта (Технологиялық стек) және MR-003, MR-006 құжаттарында егжей-тегжейлі берілген.
Ашықтық қағидатына сай (8-бөлім), осы жерде жүйенің қазіргі архитектуралық кемшілігін де атап өткен жөн: бот ядросының (main.py) көлемі уақыт өте 8 500 жолға дейін өскен, бұл — бір файл үшін өте үлкен көлем. Дәстүрлі бағдарламалық инженерия тәжірибесінде мұндай көлемдегі логика әдетте бірнеше кішірек модульге бөлінеді. Бұл — жобаның жылдам, итеративті дамуының (11-бөлім) табиғи салдары әрі болашақ жетілдіру бағыттарының бірі болып саналады (13-бөлім).
MindRelay-дің үш негізгі есептеу компоненті — бот ядросы, басқару панелі және core/ пакетінің барлық модульдері — Python тілінде жазылған. Бұл таңдаудың бірнеше нақты себебі бар: жасанды интеллект экожүйесімен үйлесімділік — OpenAI, Groq, Google Gemini сияқты барлық AI провайдерлердің ресми Python клиент кітапханалары бар; мәтінмен жұмыс істеудің ыңғайлылығы — Python-ның мәтінді өңдеу мен файлмен жұмыс істеу мүмкіндіктері Obsidian-ға негізделген дерек қоймасымен жұмыс істеу үшін табиғи түрде сәйкес келеді; жылдам әзірлеу мүмкіндігі — жалғыз әзірлеуші үшін Python-ның қарапайым синтаксисі мен үлкен кітапханалар қоры дамыту жылдамдығын арттырады.
Қазіргі уақытта жобада қолданылатын нұсқа — Python 3.13.3, бұл тілдің ең соңғы тұрақты буындарының бірі.
Flask — жүйенің екі негізгі HTTP серверінің (бот ядросы мен басқару панелі) негізінде тұрған веб-фреймворк. Django сияқты «барлығы қосылған» фреймворктердің орнына Flask таңдалуының себебі — оның жеңіл, минималистік сипаты: MindRelay-ге Django ұсынатын толық ORM, admin-панель, аутентификация жүйесі сияқты күрделі мүмкіндіктердің қажеті жоқ, себебі дерекқор ретінде реляциялық жүйе емес, Obsidian файлдық қоймасы қолданылады (6.3-тармақ).
Жалғыз Python-нан тыс негізгі backend технологиясы. Оның қолданылу себебі 5.4-тармақта толық түсіндірілген — Baileys кітапханасының JavaScript ортасына тән болуы. Node.js нұсқасы ретінде v24.16.0 қолданылады.
Flask-тың өзінің құрамындағы даму сервері (development server) тек тестілеу үшін арналған, ол бір мезгілде көп сұранысты өңдеуге, тұрақты жұмыс істеуге лайықталмаған. Сондықтан MindRelay production режимінде (1.4-тармақ) waitress кітапханасын WSGI сервері ретінде қолданады — ол Flask қосымшасын нақты, сенімді, көп ағынды түрде жұмыс істетеді.
Басқару панелінің интерфейсі HTML5, CSS3 және таза (Vanilla) JavaScript негізінде жасалған — React, Vue немесе Angular сияқты бөлек frontend-фреймворк қолданылмаған. Бұл шешімнің саналы негіздемесі бар: жеңілдік пен жылдамдық — фреймворксіз интерфейс браузерде жылдамырақ жүктеледі; құрастыру қадамының болмауы — React/Vue әдетте npm run build сияқты құрастыру процесін талап етеді, Vanilla JS мұндай қосымша қадамсыз, файлды тікелей өзгертіп, браузерді жаңарту арқылы дереу нәтиже көруге мүмкіндік береді; жалғыз әзірлеуші үшін қарапайымдылық — үлкен фреймворктің оқу қисығы мен экожүйесін меңгерудің орнына, тікелей белгілі, стандартты веб-технологияларды қолдану.
Бұл таңдаудың кері жағы да бар — үлкен интерфейстерде Vanilla JS коды құрылымсыз болып кетуі мүмкін, бұл 5.6-тармақта аталған жалпы архитектуралық шектеулермен үндес мәселе.
Басқару панеліндегі барлық статистикалық графиктер мен диаграммалар (мониторинг беті, күнделікті/апталық трендтер) Chart.js кітапханасы арқылы салынады. Бұл — жеңіл, кең тараған, HTML5 Canvas негізінде жұмыс істейтін кітапхана, ол donut, bar, line сияқты негізгі диаграмма түрлерін қолдайды.
MindRelay дәстүрлі реляциялық дерекқорлардың (MySQL, PostgreSQL, SQLite) орнына Obsidian атты, негізінен жеке білім менеджменті үшін жасалған, Markdown файлдарына негізделген жүйені қолданады. Бұл — жобаның ең ерекше сәулеттік шешімдерінің бірі, сондықтан оның негіздемесін толығырақ қарастырған жөн.
| Артықшылық | Түсіндірме |
|---|---|
| Адам оқи алатын формат | Деректер әдеттегі мәтіндік (.md) файлдар түрінде сақталады — оларды арнайы дерекқор клиентінсіз, кез келген мәтіндік редактормен тікелей оқуға болады |
| Табиғи байланыс жүйесі | Obsidian-ның өз [[wiki-link]] синтаксисі файлдар арасында сілтеме орнатуға мүмкіндік береді — бұл білім графы тұжырымдамасымен (MR-006 құжатының 8-бөлімі) табиғи түрде үйлеседі |
| Серверге тәуелсіздік | Дерекқор арнайы серверлік процесті талап етпейді — деректер тікелей файл жүйесінде жатыр, бұл сақтық көшірмелеуді жай файл көшіру дәрежесіне дейін жеңілдетеді |
| Икемді құрылым | Қатаң кестелік шектеу жоқ — әрбір Пайдаланушы папкасы (MR-003 құжатының 4.2-тармағы) өз ішінде еркін құрылымдалуы мүмкін |
Бұл таңдаудың салдары да бар — реляциялық дерекқорларға тән күрделі сұраныстар (JOIN, агрегация) мүмкін емес немесе қиынырақ жүзеге асырылады, ал үлкен көлемдегі деректерде іздеу жылдамдығы арнайы индекстелген дерекқорға қарағанда төмен болуы мүмкін. Дәл осы себепті core/rag.py модулінде арнайы ObsidianRAG жүйесі жасалған — ол Obsidian файлдарынан ақпаратты тиімді іздеп табу үшін қосымша қабат болып қызмет етеді.
Толық техникалық сипаттама, файл құрылымы және сақтау тәртібі — MR-003 (Ақпаратты жинау, өңдеу және білім қалыптастыру саясаты) және MR-006 (Білім қоры және профильдеу саясаты) құжаттарында берілген.
Жоғарыда сипатталған негізгі стектен басқа, MindRelay бірнеше мамандандырылған сыртқы қызмет пен кітапхананы қолданады, әрқайсысы белгілі бір нақты функцияға жауап береді:
| Қызмет/кітапхана | Мақсаты | Қолдану контексі |
|---|---|---|
| Google Calendar API | Иесінің кестесін тексеру | «Кесте бойынша» жұмыс режимінде N.I.R.A. Оператордың қолжетімділігін күнтізбеден автоматты анықтайды (MR-002 құжатының 4.5-тармағы) |
| OpenAI Whisper | Дауыстық хабарламаларды мәтінге түрлендіру | Пайдаланушы дауыстық хабарлама жіберген сайын, транскрипция осы қызмет арқылы жүзеге асады |
| OpenCV (cv2) | Видео файлдардан кадр алу | Видео хабарлама келгенде, жүйе автоматты түрде бірінші кадрды алып, оны AI Vision арқылы талдайды |
| pypdf | PDF құжаттарды талдау | Пайдаланушы PDF файл жіберсе, оның мәтіндік мазмұны осы кітапхана арқылы шығарылып алынады |
| python-docx | Word құжаттарын өңдеу | Word форматындағы құжаттарды оқу және өңдеу үшін |
| Twilio | SMS/қосымша байланыс арнасы | Қосымша немесе балама байланыс арнасы ретінде сыналған/қосылған |
Бұл интеграциялардың әрқайсысы жүйенің «медиа өңдеу» қабатының (MR-002 құжатының 3.6-тармағы, «Қолдау көрсетілетін мазмұн түрлері») техникалық негізін құрайды — Пайдаланушы тек мәтінмен шектелмей, дауыс, сурет, видео, құжат жібере алатынын қамтамасыз етеді.
MindRelay-дің жауап беру қабілеті түбегейлі түрде сыртқы жасанды интеллект қызметтеріне тәуелді — егер AI провайдер қолжетімсіз болса, N.I.R.A. жауап бере алмайды. Егер жүйе тек бір ғана провайдерге (мысалы, тек OpenAI-ге) тәуелді болса, сол провайдердің кез келген уақытша ақауы (сервер істен шығуы, квота таусылуы, техникалық қызмет көрсету) бүкіл MindRelay жүйесінің толық тоқтап қалуына әкелер еді.
Осы бір нүктелі істен шығу тәуекелін (single point of failure) болдырмау үшін жүйе бірыңғай емес, көп деңгейлі (fallback chain) AI-провайдер құрылымын қолданады. Бұл тәсілдің логикасы қарапайым: бірінші деңгейдегі провайдер қолжетімсіз болса, жүйе автоматты түрде екінші деңгейге ауысады; ол да қолжетімсіз болса — үшінші деңгейге. Пайдаланушы үшін бұл ауысу мүлде көрінбейді.
| Деңгей | Провайдер | Рөлі және таңдалу себебі |
|---|---|---|
| 1 (негізгі) | OpenAI (GPT-4o-mini) | Ең жоғары сапалы, дәл және мәнмәтінге сай жауаптар беру қабілетімен ерекшеленеді. Күнделікті, негізгі жұмыс режимінде осы модель қолданылады. |
| 2 (резерв) | Groq (Llama 3.3 70B) | OpenAI қолжетімсіз немесе шектен асқан жағдайда іске қосылады. Ерекшелігі — Groq-тың арнайы есептеу инфрақұрылымы (LPU) арқасында жауап беру жылдамдығы едәуір жоғары. |
| 3 (соңғы резерв) | Google Gemini (2.0 Flash-Lite) | Алдыңғы екі деңгей де қолжетімсіз болған жағдайдағы соңғы сақтық желісі. |
Бұл үш сатылы тізбек жүйенің бір ғана сыртқы қызметке тәуелді болмауын қамтамасыз етеді және кез келген сервистің уақытша қолжетімсіздігі жағдайында да боттың жұмысын тоқтатпай жалғастыра алуын кепілдендіреді.
Суреттерді талдау мүмкіндігінің тарихы — жобаның нақты техникалық шешім қабылдау тәжірибесінің көрнекі мысалы. Бастапқыда бұл функция Google Gemini Vision арқылы жүзеге асырылған болатын. Алайда Gemini-дің тегін деңгейдегі сұраныс квотасы жеткілікті түрде тез таусылды — бұл нақты өндірістік жүктеме кезінде тегін квотаның шектеулі екенін көрсеткен тәжірибелік дәлел болды. Осыдан кейін архитектура толығымен OpenAI Vision-ге ауыстырылды, және бұл ауысым қазірге дейін сақталып тұр.
Бұл оқиға 11-бөлімде («Жобаның тарихы») сипатталған даму кезеңдерінің бірі ретінде де тіркелген (11.5-тармақ) — ол жобаның тек жоспарлы түрде емес, нақты кездескен техникалық шектеулерге бейімделу арқылы да дамитынының дәлелі.
AI провайдерлерге деректерді жіберу кезіндегі қауіпсіздік шаралары (API кілттерінің құпиялылығы, шифрленген байланыс арнасы, жүйелік жазбаларда құпия ақпараттың тіркелмеуі) осы паспортта емес, арнайы MR-007 (Қауіпсіздік саясаты) құжатының 8-бөлімінде («Үшінші тарап қызметтерінің қауіпсіздігі») толық сипатталған. Ал Пайдаланушы деректерінің AI провайдерлерге қалай және не мақсатпен берілетіні — Құпиялылық саясатының (MR-001) 6-бөлімінде.
7.1–7.3-тармақтарда сипатталған үш деңгейлі тізбек — қазіргі жағдай, бірақ ол тұрақты емес. AI технологиялары саласының қарқынды дамуын ескере отырып, провайдерлер тізбегінің құрамы мен реті болашақта өзгеруі мүмкін (мысалы, жаңа, тиімдірек модель шыққанда, немесе қолданыстағы провайдерлердің баға/сапа қатынасы өзгергенде). Бұл — жүйенің 8-бөлімде аталатын «үздіксіз даму» қағидатының тағы бір көрінісі.
Бұл бөлімді дұрыс түсіну үшін алдымен бір маңызды межені белгілеп алу керек: осында сипатталатын қағидалар — жобаның өнімдік (продукттық) деңгейдегі қағидалары, яғни MindRelay жалпы алғанда қандай сипатта болуы керек, қандай бағытты ұстанады деген сұраққа жауап береді. Бұл қағидалар деректерді сақтауға қатысты философиямен (ол MR-005 құжатының 17.2 және 17.5-тармақтарында бөлек қаралған) шатастырылмауы тиіс — соңғысы нақты Пайдаланушы деректерінің меншік сипаты мен сақталу тағдырына қатысты тар мәселені қамтиды, ал мұндағы тізім жобаның тұтас, жалпы бағыты мен мінез-құлқын анықтайды.
Бұл айырмашылықты нақты мысалмен түсіндірейік: «Ашықтық» қағидаты (8.2-тармақ) — жобаның архитектурасы мен тарихы жасырылмайтынын білдіреді (өнімдік деңгей), ал MR-005 құжатындағы «ашықтық қағидасы» (16.5-тармақ) — Пайдаланушының өз профилінің мазмұнын кез келген уақытта сұрай алатынын білдіреді (деректік деңгей). Екеуі де «ашықтық» деп аталса да, әрқайсысы басқа сұраққа жауап береді.
MindRelay жобасының мақсаты, архитектурасы және даму тарихы жасырылмайды. Бұл қағидаттың нақты көрінісі — дәл осы құжаттың (Жоба паспорты) өзі: жоба өзінің ішкі құрылымын (5-бөлім), нақты өсу тарихын (11-бөлім), тіпті архитектуралық кемшіліктерін де (5.6-тармақ) ашық түрде сипаттайды. Сонымен қатар, trust_center/ компонентінің болуы (5.2.8-тармақ) — ашықтықтың техникалық деңгейде іске асырылуының дәлелі.
Пайдаланушы деректерін қорғау жобаның әр деңгейінде — архитектуралық оқшаулаудан бастап (5.2.4-тармақтағы орталықтандырылған жазу механизмі), жүйелік жазбалардың құрылымына дейін (7.4-тармақ) — ескеріледі. Бұл қағидаттың толық, техникалық деңгейдегі жүзеге асырылуы MR-007 (Қауіпсіздік саясаты) құжатында берілген.
Дербес деректер тек Пайдаланушымен келісілген, айқын мақсатта пайдаланылады — жарнамалық, коммерциялық сату немесе үшінші тұлғаға беру мақсатында пайдаланылмайды. Бұл қағидаттың толық құқықтық негіздемесі MR-001 (Құпиялылық саясаты) құжатында берілген.
Бұл қағидат, мүмкін, MindRelay-дің ең айқын сипаттайтын белгісі. Жоба тоқтап қалмайды — 11-бөлімде («Жобаның тарихы») көрсетілгендей, әр апта сайын дерлік жаңа функционал қосылып отырды, ал бұл процесс қазірге дейін жалғасуда (12-бөлім, «Қазіргі жағдай»). Бұл қағидат тікелей 4-бөлімде («Көрініс») сипатталған үш деңгейлі даму траекториясымен байланысты — егер даму тоқтаса, жоба «Жеке AI-көмекші» деңгейінде қалып қояды, «Жеке білім операциялық жүйесі» деңгейіне жете алмайды.
Ақпаратты жай сақтау емес, одан мағына мен байланыс шығару басым бағыт болып саналады. Бұл қағидат 2-бөлімде («Жобаның мақсаты») сипатталған алты бағыттың ең тереңі — ол жай ғана деректерді жинаудан гөрі, солардан жаңа білім синтездеуге басымдық берудің философиялық негізі. Практикалық деңгейде бұл қағидат MR-006 құжатының 9 және 10-бөлімдерінде («Білім элементтерін қалыптастыру» және «Білім қорының меншік сипаты») техникалық және құқықтық тұрғыдан толық ашылған.
Оқшауланған фактілер емес, өзара байланысқан тұтас контекст құру — MindRelay-дің қарапайым чат-боттан ерекшеленетін негізгі белгісі (10-бөлім, «Жобаның ерекшелігі»). Бұл қағидат нақты техникалық түрде білім графы тұжырымдамасында (MR-006 құжатының 8-бөлімі) жүзеге асырылған: жеке байланыстар уақыт өте бір-бірімен тоғысып, көп деңгейлі, бай мағыналы құрылымдарға айналады.
Осы алты қағидат бір-бірінен оқшауланған тізім емес — олар өзара тығыз байланысты. Мысалы, «Үздіксіз даму» (8.5) мен «Ашықтық» (8.2) қағидаттарының қиылысуы — жобаның әрбір өзгерісі жасырын емес, керісінше, дамудың өзі жария түрде (осы паспорт арқылы) құжатталатынын білдіреді. Дәл осылай, «Білім қалыптастыру» (8.6) мен «Ақпараттарды байланыстыру» (8.7) — 2-бөлімде сипатталған бірізді процестің (жинау → байланыстыру → білім қалыптастыру) екі көрші сатысы, сондықтан бұл екі қағидат бір-бірінсіз толық мағынаға ие болмайды.
Бұл өзара байланыс кездейсоқ емес — барлық алты қағидат, түптеп келгенде, 3-бөлімде («Миссия») тұжырымдалған бір ғана негізгі идеяның — «ақпаратты байланыстырып, білімге айналдыру» — әртүрлі қырларын білдіреді.
Мақсатты аудиторияны сипаттағанда MindRelay үшін бір ғана тізім жеткіліксіз, себебі 4-бөлімде («Көрініс») көрсетілгендей, жоба қазіргі күйінде ғана емес, ұзақ мерзімді даму траекториясында да қарастырылуы тиіс. Сондықтан аудиторияны да екі нақты уақыттық қабатқа бөліп сипаттаймыз: қазіргі, нақты қолданыстағы аудитория және болашақта көзделетін, әлі жетілмеген аудитория. Бұл екі қабат бір-бірінен түбегейлі ерекшеленеді — біріншісі жобаның қазіргі техникалық және ұйымдастырушылық мүмкіндіктеріне сай келсе, екіншісі 4-бөлімдегі даму деңгейлерімен тікелей байланысты.
Бұл санатты ерекше атап өту маңызды, себебі MindRelay бастапқыда (11.2-тармақ, «Жобаның тарихы») дәл осы адамның жеке қажеттілігінен туындаған: дислексиямен күресу, барлық мессенджерлерді біріктіру, ақпарат пен күн тәртібін басқару. Демек, автор — жай тестілеуші немесе әкімші емес, жүйенің бастапқы, бірінші дизайн-мақсаты болған нақты пайдаланушы. Бұл жағдай MindRelay-дің көптеген жобалардан ерекшеленетін тұсы: функциялар алдымен абстрактілі «орташа пайдаланушыға» емес, нақты, өлшенетін жеке қажеттілікке жауап ретінде жасалған.
Автордан басқа, MindRelay-мен байланысатын жеке адамдар — WhatsApp немесе Telegram арқылы N.I.R.A.-ға хабарласатын, өз сұрақтарын қоятын, сұраныс (zapros) қалдыратын Пайдаланушылар (толық құқықтық анықтамасы — MR-002 құжатының 2-бөлімі, «Терминдер мен анықтамалар»). Бұл санатқа, атап айтқанда, автормен байланыс жасайтын клиенттер, серіктестер, таныстар кіреді.
N.I.R.A. жеке диалогтармен қатар, топтық чаттарға да қатыса алады (толық техникалық сипаттама — MR-002 құжатының 3.4-тармағы және MR-003 құжатының 2-бөлімі). Бұл жағдайда аудитория жеке адам емес, шағын топ немесе қауымдастық болып табылады — мұндағы өзара әрекеттесу сипаты жеке чаттан өзгеше (мысалы, N.I.R.A. әдепкі бойынша топта жария жауап бермейді, тек тыңдайды).
Бұл санаттар 4-бөлімде сипатталған даму деңгейлерімен тікелей байланысты — әрбір келесі аудитория түрі жүйенің тиісті деңгейге жетуін талап етеді.
MindRelay-дің «Жеке білім операциялық жүйесі» (4.2.1-тармақ) деңгейіне жетуі — оны бір адамға емес, тұтас ұйымға қызмет ете алатын жүйеге айналдырудың алғышарты. Бұл кеңею MindRelay Пайдалану шарттарының (MR-002) 1.10-тармағында да алдын ала ескерілген: «Платформа болашақта үшінші тұлғаларға өз атынан және өз мақсаттарында пайдалану үшін ұсынылуы мүмкін», мұндағы «иеленуші» ұғымы дәл осы ұйымдық аудиторияға сәйкес келеді.
«Цифрлық жады жүйесі» (4.2.2-тармақ) деңгейінің табиғи қолданылу аясы — білім беру. Оқу материалдарын, курс құрылымын, оқушылардың сұрақтары мен жауаптарын байланыстырып, білім графы (MR-006 құжатының 8-бөлімі) түрінде құрылымдау — білім беру жобалары үшін ерекше құнды болуы мүмкін.
«Екінші ми» платформасы (4.2.3-тармақ) деңгейі — зерттеу жұмысының табиғатына тікелей сәйкес келеді: зерттеушілер көбіне үлкен көлемдегі ақпарат, дереккөз, идея арасында байланыс іздейді, дәл осы MindRelay-дің негізгі мақсаты (2-бөлім). Зерттеу топтары үшін жүйе ортақ білім қорын қалыптастырушы құрал бола алады.
Аудиторияның жеке пайдаланушыдан ұйымдарға дейін кеңеюі 8-бөлімде сипатталған «Үздіксіз даму» қағидатының тікелей салдары. Бірақ бұл кеңею 8.4-тармақтағы «Құпиялылық» қағидатымен теңгерімделуі тиіс — атап айтқанда, MR-002 құжатының 1.10-тармағында әрбір «иеленуші» өз Пайдаланушыларына қатысты дербес оператор болатыны, дербес деректерді өңдеуге дербес жауапты болатыны нақты көрсетілген. Демек, аудиторияның кеңеюі жауапкершіліктің де тиісті түрде бөлінуін талап етеді — бұл мәселе жаңа санаттар нақты іске асқан кезде тиісті құқықтық құжаттарда толығырақ реттелетін болады.
MindRelay-ді сырттан бірінші рет көрген адам оны оңай «тағы бір WhatsApp-бот» деп қабылдап қоюы мүмкін — қазір нарықта ондаған, тіпті жүздеген ұқсас көрінетін чат-боттар бар. Сондықтан жобаның нақты немен ерекшеленетінін дәл, нақты дәлелдермен көрсету қажет — жалпы сөзбен «біз ерекшеміз» деу емес, техникалық және сәулеттік деңгейде нақты айырмашылықты көрсету.
Ерекшелікті ең анық көрсету тәсілі — MindRelay нені істемейтінін және нені істейтінін қатар қою:
| MindRelay ЕМЕС | MindRelay — БҰЛ |
|---|---|
| ❌ Жай чат-бот | ✅ Білім қалыптастыру жүйесі |
| ❌ Жай ақпарат базасы | ✅ Байланыстарды анықтау жүйесі |
| ✅ Интеллектуалдық көмекші |
Бұл кестенің құрылымы кездейсоқ емес: сол жақ баған — сырттан қарағанда MindRelay-ге ұқсас көрінетін, бірақ негізінен басқа екі санат («чат-бот» және «ақпарат базасы»), ал оң жақ баған — осы екі санаттың әрқайсысынан нақты немен ерекшеленетінін көрсететін үш нақты сипаттама.
Әдеттегі чат-бот белгілі бір сценарий бойынша жұмыс істейді: сұрақ келеді → алдын ала жазылған жауап немесе шектеулі логика бойынша жауап беріледі → диалог аяқталады, іс жүзінде із қалдырмайды. MindRelay мұнан үш нақты жолмен ерекшеленеді: контекст сақталады (MR-006 құжатының 4-бөлімі) — диалог аяқталғанмен, одан алынған факт пен байланыс жоғалмайды; жауап статикалық емес — N.I.R.A. сол бір сұраққа әр түрлі уақытта әр түрлі, контекстке бейімделген жауап бере алады (MR-002 құжатының 8.2.4-тармағы); диалогтан тыс дамиды — жүйенің өзін-өзі үйрету механизмі (MR-005 құжатының 3-бөлімі) диалогтан тыс, түнде де жұмыс істейді.
Әдеттегі ақпарат базасы (мысалы, кәдімгі дерекқор немесе құжат қоймасы) деректерді сақтайды, бірақ олардың арасында өз бетінше байланыс іздемейді — іздеу тек нақты сұраныс бойынша, пассивті түрде жүзеге асады. MindRelay мұнан белсенді, өз бетінше байланыс анықтау қабілетімен ерекшеленеді: автоматты байланыс анықтау (MR-006 құжатының 7.8-тармағы) — «байланыстар жасанды интеллект арқылы... автоматты түрде анықталады, Пайдаланушыдан бөлек растау талап етілмейді»; көп деңгейлі құрылым (MR-006 құжатының 8-бөлімі, «Білім графтары») — жеке байланыстар уақыт өте бір-бірімен тоғысып, «Ернат → MindRelay → N.I.R.A. → Arduino → Робототехника → Фаетон жобасы» сияқты көп қабатты тізбектерге айналады; меншік сипатының өзгеруі (MR-006 құжатының 10-бөлімі) — өңделген ақпарат бастапқы дереккөзден ажыратылып, жаңа, дербес құндылыққа ие болады, бұл әдеттегі ақпарат базасында мүлде жоқ қасиет.
Жоғарыда келтірілген дәлелдердің барлығы үш нақты бөлімге негізделеді, оларды тереңірек зерттегісі келетін оқырманға арнайы көрсетеміз: 5-бөлім (осы құжатта, «Жүйе архитектурасы») — компоненттердің көптүрлілігі: жай хабарлама алмасу үшін core/ пакетінің тоғыз модулі, білім графы, RAG жүйесі қажет болмас еді; 7-бөлім (осы құжатта, «AI провайдерлерінің көп деңгейлі құрылымы») — жай сценарийлі бот үшін үш деңгейлі fallback тізбегі артық болар еді, бұл — терең, тұрақты интеллектуалдық қызметке инвестиция салынғанының белгісі; MR-006 құжатының 8 және 10-бөлімдері («Білім графтары» және «Білім қорының меншік сипаты») — бұл екі бөлім жобаның ең тереңгі, ең концептуалды қабатын құрайды.
Бұл бөлімде сипатталған үш ерекшелік («жай чат-бот емес», «жай ақпарат базасы емес», «интеллектуалдық көмекші») кездейсоқ емес — олар 3-бөлімде тұжырымдалған миссияның («ақпаратты байланыстырып, білімге айналдыру») тікелей техникалық көрінісі. Егер жоба тек чат-бот немесе тек ақпарат базасы болғанда, миссия орындалмас еді: чат-бот байланыстырмайды, ақпарат базасы білімге айналдырмайды. Дәл осы екі шектеуден бір мезгілде асып түсу — MindRelay-дің өзіндік ерекшелігінің құрылымдық негізі.
Бұл бөлімде келтірілген барлық дата, оқиға және тікелей дәйексөз — ойдан шығарылған немесе жалпылама сипатта емес, нақты тексерілген дереккөзге негізделген: жобаның бастапқы кезеңдеріндегі нақты сөйлесу тарихы, және автордың жергілікті жерде іске қосқан, тек оқитын инвентаризация скриптінің нәтижесі (файлдардың нақты өзгерту даталары мен көлемдері). Бұл әдіснамалық тазалық маңызды, себебі көптеген жобалардың «тарихы» кейін еске түсіріліп, идеалдандырылып жазылады — ал мұндағы хронология архивтік деректермен тікелей расталған.
Жоба 2026 жылғы 6 маусымда, автордың: «Давай жана проект бастайык» деген қарапайым ұсынысынан басталды. Нақты не жасау керектігі сұралғанда, жауап: «ии агент жасағым келеді» болды. Бұл — жобаның атауы, архитектурасы, тіпті нақты функциялары әлі анықталмаған, тек жалпы идея деңгейіндегі бастапқы нүкте еді.
Кейінгі нақтылау барысында автордың сұранысы үш нақты, бір-бірінен ерекшеленетін міндетке жіктелді:
| № | Міндет | Түпкі себебі |
|---|---|---|
| 1 | Дислексиямен күресу | Автордың өзінің жазу қателерін үш тілде (қазақша, орысша, ағылшынша) автоматты түрде түзету қажеттілігі — жобаның ең жеке, ең адами түрткісі |
| 2 | Байланыс арналарын біріктіру | Барлық мессенджерлерден келген хабарламаларды бір жерден басқарып, автор атынан жауап беру |
| 3 | Ақпарат жинау және күн тәртібін басқару | Адамдардан келген сұраныстарды өңдеп, автордың назарына жеткізу |
Бұл үш міндеттің біріктірілуі маңызды: MindRelay бастапқыда бір ғана мәселені шешетін құрал ретінде емес, үш түрлі жеке қажеттілікті бір жүйеде біріктіру идеясы ретінде туды. Дәл осы «біріктіру» принципі кейін жобаның негізгі миссиясына («ақпаратты байланыстырып, білімге айналдыру», 3-бөлім) дейін дамыды.
Сол бір сессияның өзінде бірнеше негіздемелі техникалық таңдау жасалды: Платформалар — WhatsApp және Telegram (екеуі де таңдалды, біреуі емес); Дерек қоймасы — Obsidian, жергілікті (local) режимде — бұлттық баламалар қарастырылмады; Алғашқы даму жоспары — төрт кезеңге бөлінген: Кезең 1 — Telegram-бот + дислексия түзету; Кезең 2 — WhatsApp интеграциясы; Кезең 3 — Obsidian автоматты жазу; Кезең 4 — Күн тәртібін басқару.
Бұл бастапқы төрт кезеңдік жоспарды 11.5-тармақтағы нақты дамыту тарихымен салыстыру қызық: жоспар сызықтық (біртіндеп) болса, нақты даму көп бағытты әрі әлдеқайда жылдам жүрді — бұл кез келген бағдарламалық жобаға тән құбылыс.
Жобаның екінші күні — даму қарқынының ерекше көрсеткіші. Бір-ақ күнде мыналардың барлығы дерлік бір мезгілде құрылды: Басқару панелінің алғашқы нұсқасы (dashboard); Google Calendar интеграциясы; Білім графының бастапқы нұсқасы (knowledge_graph.py файлы); Чаттар беті.
Бұл «жарылыс тәрізді» өсім кездейсоқ емес — ол автордың бастапқы идеясы жеткілікті нақты әрі толық ойластырылған болғанын, сондықтан оны кодқа айналдыру процесінің тым баяуламағанын көрсетеді. Дегенмен, мұндай жылдам бастапқы құрылыс кейінгі кезеңдерде (11.5-тармақ) құрылымдық қайта қарауды талап еткен жерлер де болды (мысалы, «История чатов толық қайта құрылымдалуы»).
Ассистенттің есімін таңдау — жобаның ең есте қаларлық, әрі жобаның «жаны» қашан пайда болғанын көрсететін сәт. Бұл процесс бірнеше нақты кезеңнен өтті:
Қазақша нұсқалар: «Жарқын» (жарық, ақылды деген мағынада), «Сенім» — бірақ бұлар автордың қалауына сай келмеді;
Халықаралық, «ARIA» бағыты: Artificial Relay Intelligence Assistant деген толық ашылымы ұсынылды;
Нақтылау сұранысы: автор «ARIA осы сяқты, бірақ басқаша» деп нақтылады — бұл дәл сол дыбыстық үлгіні сақтай отырып, жаңа мағына іздеу қажеттілігін білдірді;
A-R-I-A форматындағы нұсқалар: MIRA (Mind Intelligent Relay Assistant), VERA (Virtual Ernat Relay Assistant), KIRA (Knowledge Intelligent Relay Assistant), NIRA (Neural Intelligent Relay Assistant) ұсынылды;
Түпкі таңдау: автор «NIRA болсын аты» деп шешім қабылдады.
NIRA атауы кейін ресми құжаттарда N.I.R.A. (нүктелермен) түрінде бекітілді (1.3-тармақты қараңыз). Бұл атаудың Relay бөлігі — MindRelay атауымен үндес, ал бұл кездейсоқ емес: атау жеке тұлға ретінде ойлап табылғанымен, ол әлі де жүйенің үлкенірек бренді — MindRelay-мен байланыста қалуы маңызды болды.
Атау таңдалғаннан кейін, дереу сол сессияда Ассистенттің мінез-құлқы да анықталды: эмодзи қолданатын; достық тонда сөйлесетін; қысқа жауап беретін, бірақ Пайдаланушы қаласа, толығырақ ақпарат бере алмайтынын ашық айтатын; жылы әрі мейірімді; диалогты бастаған тілде жалғастыратын, ал тілді анықтау қиын болса, Пайдаланушыдан қай тілде сөйлескісі келетінін нақтылап сұрайтын; түсінбеген жағдайда өзінен ештеңе ойлап таппай, нақтылау сұрағын қоятын.
Бұл мінез сипаттамасының соңғы тармағы — «ештеңе ойлап таппайды» деген талап — кейін MindRelay Пайдалану шарттарының (MR-002) 8.7-тармағында («Қателер мен дәлдік шектеулері») құқықтық тұрғыда бекітілген принциппен тікелей үндеседі.
Бұл кезең — жобаның ең қарқынды даму фазасы, әрі ол тек сапалы сипаттамамен емес, нақты сандық дәлелмен де расталады. Бот ядросының (main.py) көлемін өлшеу арқылы алынған дерек:
| Күні | main.py көлемі | Алдыңғы өлшемнен өсім |
|---|---|---|
| 23 маусым 2026 | 2 692 жол | — (бастапқы өлшем) |
| 27 маусым 2026 | 2 796 жол | +104 жол (4 күнде) |
| 29 маусым 2026 | 3 416 жол | +620 жол (2 күнде) |
| 7 шілде 2026 | 4 315 жол | +899 жол (8 күнде) |
| 9 шілде 2026 | 5 140 жол | +825 жол (2 күнде) |
| 14 шілде 2026 | 6 282 жол | +1 142 жол (5 күнде) |
Бұл кестеден байқалатын заңдылық — өсу қарқыны тұрақты емес, толқын тәрізді: кейбір екі-үш күндік аралықта жүздеген жол қосылса (мысалы, 27→29 маусым), басқа кездерде өсім баяулаған. Бұл — жеке әзірлеушінің жұмыс ырғағына тән құбылыс, сондай-ақ әрбір үлкен секіріс, әдетте, бір үлкен функцияның қосылуымен сәйкес келеді.
Диалог контексі мен жады жүйесін жетілдіру. Бастапқы нұсқада N.I.R.A. әрбір хабарға бөлек жауап беріп, диалогтың алдыңғы бөлігін «ұмытатын» — бұл MindRelay-дің негізгі мақсатына («контекст сақтау», 2.2.5-тармақ) тікелей қайшы келетін кемшілік еді. Түзету ретінде соңғы 5 хабар толық түрде, ал одан бұрынғылары AI арқылы қысқартылған қорытынды түрінде сақталатын жүйе құрылды.
«Жасырын миссия» — ақпарат жинау жүйесі. Автордың: «бот тек жауап бермей, адамдар туралы ақпарат жинап, білім базасын дамыта берсін» деген нақты талабына сай, диалогтан фактілерді автоматты түрде бөліп алатын, оларды Obsidian құрылымына (Контактілер/Категория/Аты) құрылымдап жазатын механизм жасалды. Бұл — қазіргі MR-003 құжатының негізгі техникалық өзегі осы кезеңде қаланғанын білдіреді.
Медиа қолдауын қосу. Бот тек мәтінмен шектелмей, дауыстық хабарлама, сурет, видео, құжат қабылдай алатындай кеңейтілді. Дәл осы кезеңде 7.3-тармақта сипатталған Google Gemini Vision → OpenAI Vision ауысуы орын алды.
Dashboard негізгі беттерінің құрылуы. Мониторинг, Отчет бота, Управление ботом сияқты негізгі беттер жобаланып, бағдарламаланды — 5.2.5-тармақта сипатталған басқару панелінің функционалдық негізі осы кезде қаланды.
WhatsApp LID/нөмір мәселесінің шешілуі. Хабарлама жіберу функционалын тестілеу кезінде WhatsApp-тың ішкі идентификаторы (LID) мен нақты телефон нөмірі арасындағы айырмашылық көптеген қатеге алып келді — кейбір контактілерге хабарлама жетпей қалды. Бұл мәселе нөмір форматын автоматты анықтайтын және сай форматты таңдайтын логика қосу арқылы шешілді.
История чатов толық қайта құрылымдау. Бастапқы нұсқа тек /api/inbox-тен оқитын, контакт аттарын дұрыс көрсете алмайтын еді — бұл 11.3-тармақтағы «жарылыс тәрізді» жылдам құрылыстың салдары болуы мүмкін, себебі жылдам жасалған алғашқы нұсқалар көбіне кейін толық қайта қаралуды талап етеді.
Осы күні жоба техникалық дамудан бөлек, заңдық-сенімділік құжаттамасын жүйелі түрде жасай бастады. Реттілік бойынша жарияланды: Құпиялылық саясаты (MR-001) → Пайдалану шарттары (MR-002) → Ақпаратты жинау, өңдеу және білім қалыптастыру саясаты (MR-003) → Деректерді сақтау және жою саясаты (MR-005) → Білім қоры және профильдеу саясаты (MR-006) → Қауіпсіздік саясаты (MR-007) → Жоба паспорты (MR-008) — осы құжат.
Бұл кезеңнің маңызы зор: ол жобаның тек «жұмыс істейтін код» дәрежесінен «есеп беретін, ашық жоба» дәрежесіне өткенін білдіреді (8.2-тармақтағы «Ашықтық» қағидатының нақты іске асырылуы). MR-004 нөмірі («Жауапкершілікті шектеу» болуы ықтимал) әдейі бос қалдырылды — ол қазіргі уақытта ToS-тың 10-бөлімімен қамтылған деп есептеліп, бөлек құжат ретінде кейінге қалдырылды.
Бот ядросы 8 583 жолға (441 КБ) жетті. Бұл көрсеткішті 11.2-тармақтағы бастапқы нүктемен (6 маусымдағы нөл) салыстырғанда, шамамен екі айда жүзден астам есе өсім байқалады. Дегенмен, бұл сандық өсім 5.6-тармақта аталған архитектуралық шектеуді де тудырды — бір файлдың мұндай көлемге жетуі құрылымдық жағынан жетілдіруді қажет ететін мәселе ретінде танылған.
2026 жылғы 2 маусым — 2 шілде аралығында, дәл MindRelay-мен қатар уақытта, автор Faethon атты қосымша, физикалық жоба жасады — Arduino мен RGB LED негізіндегі, қол қимылымен басқарылатын сенсорлы интеллектуалды шам. Атаудың өзі ежелгі грек мифологиясындағы Фаэтоннан («жарқыраушы, сәуле шашушы») алынған.
Бұл жоба «Аяқталды» деп белгіленген, бірақ оның MindRelay үшін маңызы жойылған жоқ — керісінше, оның атауы MindRelay-дің білім графы тұжырымдамасының ең көрнекі мысалына айналды: «Ернат → MindRelay → N.I.R.A. → Arduino → Робототехника → Фаетон жобасы» (MR-006 құжатының 8.2.2-тармағы).
Бұл — тек ойдан шығарылған иллюстрация емес, автордың нақты, параллель жасаған екінші жобасының шынайы көрінісі, әрі MindRelay-дің «байланыстарды анықтау» қабілетінің (10.4-тармақ) өзін-өзі көрсететін мысалы: жүйе өз мысалдарын да автордың нақты өмірінен алады.
| Күні | Оқиға |
|---|---|
| 6 маусым | Жоба басталды (үш мотивация анықталды) |
| 7 маусым | Жарылыс тәрізді бірінші күн (dashboard, calendar, graph) |
| 2 маусым — 2 шілде | Faethon жобасы (параллель, тәуелсіз) |
| 11 маусым | Қоштасу жүйесі қосылды |
| 14 маусым | Атау беру: N.I.R.A. + мінез анықталды |
| 23 маусым | main.py: 2 692 жол |
| 29 маусым | main.py: 3 416 жол |
| 7 шілде | main.py: 4 315 жол |
| 9 шілде | main.py: 5 140 жол |
| 14 шілде | main.py: 6 282 жол |
| 1 тамыз | Trust Center басталды (MR-001-ден бастап) |
| 1–2 тамыз | main.py: 8 583 жол (қазіргі көлем) |
| 6 тамыз | MR-006, MR-007, MR-008 аяқталды (бүгін) |
MindRelay қазіргі уақытта (2026 жылғы 6 тамыз) толық жұмыс істейтін, өндірістік режимдегі жүйе (1.4-тармақта аталған мәртебеге сәйкес). Бұл — теориялық немесе демонстрациялық сипаттағы жоба емес: бот нақты уақытта WhatsApp және Telegram арқылы клиенттермен сөйлеседі, олардан келген ақпаратты өңдейді, ал автор басқару панелі арқылы осы бүкіл процесті тікелей бақылап, қажет болғанда араласа алады.
Бұл «толық жұмыс істейтін» деген анықтаманың нақты мазмұнын ашу үшін, жүйенің әр бөлігінің қазіргі күйін жеке-жеке қарастырған жөн.
5-бөлімде («Жүйенің архитектурасы») сипатталған басқару панелінің (dashboard/app.py) барлық негізгі беттері сынақтан толық өтіп, тұрақты жұмыс істеп тұр:
| Бет | Қызметі |
|---|---|
| Дашборд | Жалпы статистика мен жүйенің ағымдағы жай-күйін бір көзқараста көрсету |
| Мониторинг | Диалогтардың, бағалардың, белсенділіктің егжей-тегжейлі бақылауы |
| Отчет бота | Ботты жұмыс сапасы бойынша қорытынды есеп |
| Управление ботом | Ботты тікелей басқару — режимдерді өзгерту, хабарлама жіберу, параметрлерді реттеу |
| История чатов | Барлық диалогтардың тарихын қарау және іздеу |
| Obsidian база | Дерек қоймасын тікелей веб-интерфейс арқылы шолу |
Осы беттердің әрқайсысының «сынақтан өтуі» деген тұжырым кездейсоқ емес — 11.5-тармақта сипатталғандай, кейбір беттер (мысалы, История чатов) бастапқы нұсқасында толық жұмыс істемей, кейін толық қайта құрылымдалуды қажет еткен. Демек, «қазіргі тұрақтылық» — тек жаңа функция қосудың емес, сонымен қатар табылған кемшіліктерді түзетудің де нәтижесі.
MindRelay-ге өзінің негізгі, қызметтік функционалынан тыс, қосымша гейміфикация қабаты да енгізілген. Бұл қабат мыналарды қамтиды: RPG статистикасы — жүйенің немесе Пайдаланушының белгілі бір көрсеткіштерін рөлдік ойын стиліндегі статистика түрінде көрсету; Квест/дағды жүйесі — белгілі бір мақсаттарға жетуге бағытталған тапсырмалар мен дағдыларды дамыту механизмі; XP/деңгей жүйесі — тәжірибе ұпайлары мен деңгейлерге негізделген прогресс көрсеткіші; Жетістіктер (achievements) — белгілі бір межелерге жеткенде берілетін атаулар немесе белгілер.
Бұл қабаттың болуы — MindRelay-дің тек «құрғақ» функционалдық құрал ғана емес, сонымен қатар Пайдаланушы тәжірибесін (соның ішінде автордың өзінің тәжірибесін) қызықты әрі ынталандырушы етуге тырысатынының көрінісі. Гейміфикация элементтері 8-бөлімде аталған қағидаттардың бірде-біреуіне тікелей қайшы келмейді, керісінше, «Үздіксіз даму» қағидатының (8.5-тармақ) күнделікті мотивациялық құралы ретінде қызмет етеді.
MindRelay-дің басқа қарапайым чат-боттардан ерекшеленетін бір маңызды сипаты (10-бөлім) — оның диалогтан тыс та, өз бетінше дамитын механизмдері бар. Бұл механизмдер қазіргі уақытта белсенді жұмыс істейді: Түнгі өзін-өзі тестілеу — жүйе белгілі бір уақыт аралығында (түнде) өзінің бұрынғы жауаптарын қайта қарап, сапасын бағалайды; Ереже ұсыну жүйесі — жүйе өз тәжірибесінен қорытынды шығарып, жаңа мінез-құлық ережелерін ұсынады (бұл ұсыныстар автоматты түрде күшіне енбейді, олар Оператордың бекітуін талап етеді); Тақырыпты өзін-өзі кеңейту — жаңа, бұрын анықталмаған тақырыптарды дербес тануы және білім графына қосуы; Баға трендін бақылау — Пайдаланушылардан алынған бағалардың уақыт бойынша қалай өзгеретінін бақылап, тенденцияны анықтау; Автоматты FAQ қалыптастыру — жиі қойылатын сұрақтарды анықтап, оларға дайын жауаптар базасын құру.
Бұл тізім MR-003 (Ақпаратты жинау, өңдеу және білім қалыптастыру саясаты) және MR-006 (Білім қоры және профильдеу саясаты) құжаттарында толығырақ, техникалық және құқықтық тұрғыдан сипатталған — атап айтқанда, бұл механизмдердің қалай Пайдаланушы деректерінің құпиялылығын сақтай отырып жұмыс істейтіні (мысалы, білім элементтерінің анонимдендірілуі, MR-006 құжатының 9.8.2-тармағы) сол құжаттарда толық ашылған.
Осы бөлімде сипатталған үш деңгей — негізгі функционал (12.2), қосымша тәжірибе қабаты (12.3), және өзін-өзі дамыту механизмдері (12.4) — бірге алғанда, MindRelay-дің 4-бөлімде сипатталған «Жеке AI-көмекші» деңгейінен «Жеке білім операциялық жүйесі» деңгейіне өту жолында қазір нақты қай жерде тұрғанын көрсетеді: негізгі функционал толық тұрақтанған, ал жүйенің өз бетінше дамуы мен байланыс анықтау қабілеті (білім графы, өзін-өзі жетілдіру) белсенді, бірақ әлі жетілу үстінде.
Бұл бөлім екі өзара байланысты, бірақ мәні бөлек сұраққа жауап береді: не үшін бұл жобаны жасап жатырмыз (күтілетін нәтижелер — идеалды, түпкі мақсатқа қатысты) және нақты не істеп жатырмыз (даму бағыттары — таяу болашақтағы, нақты жоспарланған қадамдар). Біріншісі 2-бөлімдегі («Жобаның мақсаты») алты бағытпен тікелей үндессе, екіншісі 12-бөлімдегі («Қазіргі жағдай») сипатталған нақты техникалық негізден өсіп шығады.
Бұл тізім — MindRelay жобасының сәттілігін өлшейтін түпкі критерийлер. Әрқайсысы 2-бөлімдегі белгілі бір мақсатпен тікелей байланысты:
| Күтілетін нәтиже | 2-бөлімдегі сәйкес мақсат |
|---|---|
| Ақпараттарды құрылымдау | «Ақпарат жинау» (2.2.1-тармақ) |
| Контекстті сақтау | «Контекст сақтау» (2.2.5-тармақ) |
| Білім қалыптастыру | «Білім қалыптастыру» (2.2.3-тармақ) |
| Қайталанатын сұрақтарды азайту | «Контекст сақтау» мен «Интеллектуалдық көмек көрсетудің» практикалық салдары |
| Идеяларды дамыту | «Идеяларды дамыту» (2.2.4-тармақ) |
Бұл кестеден байқалатын заңдылық — күтілетін нәтижелер жаңа, бөлек тізім емес, олар 2-бөлімде тұжырымдалған мақсаттардың өлшенетін, тексерілетін нұсқасы. Мысалы, «Қайталанатын сұрақтарды азайту» — бұл дерексіз идея емес, іс жүзінде тексеруге болатын көрсеткіш: егер MindRelay жақсы жұмыс істесе, N.I.R.A. бір Пайдаланушыдан бұрын берілген ақпаратты (мысалы, оның қызығушылығын немесе жобасын) қайта сұрамауы тиіс (толығырақ — MR-006 құжатының 4.5-тармағы, «Қайталанатын сұрақтарды азайту»).
Бұл тізім, керісінше, нақты, таяу болашаққа арналған техникалық қадамдар. Әрқайсысын жеке қарастырайық.
Қазіргі уақытта басқару панелі (5.2.5-тармақ) тек веб-браузер арқылы қолжетімді. Мобильді нұсқаның болмауы автордың (немесе болашақ ұйымдық Пайдаланушылардың, 9.3.1-тармақ) жол-сапарда, компьютерден тыс жерде жүйені бақылау мүмкіндігін шектейді. Push-хабарлама жүйесі мұнымен тікелей байланысты — маңызды оқиға (мысалы, жаңа сұраныс немесе қауіпсіздік ескертуі, MR-007 құжатының 10.5-тармағы) болғанда, автор дереу хабардар болуы үшін қажет.
6.4-тармақта сипатталғандай, қазіргі уақытта видео файлдар OpenCV арқылы бір кадр алу тәсілімен талданады. Бұл — жеңілдетілген тәсіл, себебі бір кадр видеоның толық мазмұнын бере алмайды. Жоспарланған кеңейту екі бағытта жүреді: бірнеше кадр алу (видеоның әр түрлі сәттерін қамту) және дауыс транскрипциясы (видеодағы дыбыс жолын да OpenAI Whisper арқылы мәтінге түрлендіру). Бұл жетілдіру толымдырақ жүзеге асса, видео хабарлама сурет пен дауыстық хабарламамен теңдей толық өңделетін болады.
Бұл функция — Оператордың кез келген уақытта диалогқа өзі қосылып, N.I.R.A.-ның орнына жауап беру құқығы (толық құқықтық негіздеме — MR-002 құжатының 4.4-тармағы, «Оператордың қатысуы»). Техникалық тұрғыдан бұл функция config/ пакетінде (manual_takeover.json) және бот ядросында жүзеге асырылған, бірақ ол әлі толық тестіленбеген, тұрақтылығы жетілдіруді қажет ететін аймақ болып қала береді.
4-бөлімде («Көрініс») сипатталған үш деңгейлі даму траекториясының 1-деңгейіне («Жеке білім операциялық жүйесі») жету үшін, басқару панелі жай статистика көрсететін интерфейстен нақты басқару орталығына айналуы тиіс. Бұл бағыт — қазіргі Dashboard функционалын (12.2-тармақ) тереңдету, кеңейту, жаңа мүмкіндіктермен толықтыру процесі.
4-бөлімдегі 5-деңгейге («Кеңейтілген экожүйе») жету жолындағы қадам. Қазіргі уақытта білім графы негізінен адам-жоба-тақырып үштігі аясында жұмыс істейді (MR-006 құжатының 7-бөлімі); кеңею — бұл құрылымға жаңа түйін түрлерін, тереңірек байланыс деңгейлерін қосу дегенді білдіреді.
Бұл екі тізімнің арасындағы байланысты нақты көрсету маңызды: даму бағыттары (13.3) — күтілетін нәтижелерге (13.2) жетудің құралдары, өздігінен мақсат емес. Мысалы, «Видео файлдарды талдауды кеңейту» (13.3.2) өз алдына мақсат емес — ол «Ақпараттарды құрылымдау» (13.2) деген түпкі нәтижеге қызмет етеді, себебі неғұрлым толық талданған видео, соғұрлым дәлірек құрылымдалған ақпарат алынады.
Осы принципті ескере отырып, кез келген жаңа даму бағытын бағалағанда қолданылатын сұрақ мынау: бұл қадам 13.2-тармақтағы бес күтілетін нәтиженің қайсысына қызмет етеді? Егер жауап табылмаса, ол бағыт MindRelay-дің негізгі миссиясынан (3-бөлім) ауытқып бара жатқанын білдіруі мүмкін.
Бұл құжаттың соңына жақын орналасуы кездейсоқ емес — философия бөлімі, әдетте, алдыңғы бөлімдердің барлығын (мақсат, миссия, көрініс, архитектура, тарих, қазіргі жағдай, болашақ жоспарлар) біріктіретін, соларға негіз болатын қорытынды тұжырым ретінде қызмет етеді. Басқаша айтқанда, 2–13-бөлімдер «не» және «қалай» деген сұрақтарға жауап берсе, бұл бөлім — «неге түбінде осылай» деген сұраққа жауап береді.
8-бөлімде («Негізгі қағидалар») аталған ескертуді осы жерде қайта, енді нақтырақ тұжырыммен растау қажет: бұл — жобаның өнімдік (продукттық) философиясы. MR-005 құжатының 17.2-тармағында мүлде бөлек, деректік философия қаралған — ол Пайдаланушы мен MindRelay арасындағы меншік теңгерімін түсіндіреді: Пайдаланушы өз бастапқы ақпаратына құқыққа ие, ал MindRelay сол ақпаратты өңдеу нәтижесінде қалыптасқан жалпыланған білімге құқылы (толық түсіндірме — MR-006 құжатының 10-бөлімі, «Білім қорының меншік сипаты»).
Бұл екі философияны шатастырмау үшін, олардың әрқайсысы қандай сұраққа жауап беретінін нақты ажыратып көрсетейік:
| Өнімдік философия (осы бөлім) | Деректік философия (MR-005 §17.2) | |
|---|---|---|
| Сұрағы | MindRelay не үшін бар? | Пайдаланушы мен жүйенің деректерге қатысты құқығы қандай? |
| Мазмұны | Ақпаратты байланыстыру мен білім қалыптастырудың мәні | Меншік теңгерімі, жою құқығының шегі |
| Қолданылу аясы | Жобаның жалпы бағыты, миссиясы | Нақты құқықтық/техникалық мәселелер |
«MindRelay мақсаты ақпараттарды жай сақтау емес. Жоба ақпараттар арасындағы байланыстарды анықтап, олардан жаңа білім, түсінік және идеялар қалыптастыруға бағытталған.»
Бұл тұжырымды бөлшектеп қарастырайық — әрбір сөзінің салмағы бар. «ақпараттарды жай сақтау емес» — бұл теріске шығару арқылы басталуы маңызды: MindRelay пассивті архив, «дерек қоймасы» болудан бас тартады. «байланыстарды анықтап» — бұл етістік белсенді, іздену сипатында берілген, «сақтап» немесе «жинап» емес — бұл сөз таңдауы MR-006 құжатының 7.8-тармағында сипатталған автоматты байланыс анықтау механизмімен дәл сәйкес келеді. «жаңа білім, түсінік және идеялар қалыптастыруға» — бұл тіркес үш бөлек ұғымды қатар қояды: білім (жүйелі, құрылымдалған факт), түсінік (тереңірек, мәнмәтіндік мағына) және идеялар (жаңа, синтезделген ұсыныс).
Бұл философиялық тұжырым оқшауланған сөйлем емес — ол осы құжаттың басынан аяғына дейін өтетін бір желінің түйіні: 3-бөлімдегі миссиямен («ақпаратты байланыстырып, білімге айналдыру») дерлік бірдей идея, тек тереңірек, түсіндірмелі түрде қайталанған; 4-бөлімдегі көріністен («Екінші ми» платформасы) — бұл философия сол алыс болашақтың неге қажет екенін негіздейді; 8-бөлімдегі қағидалармен («Білім қалыптастыру», «Ақпараттарды байланыстыру») — бұл философияның операциялық, күнделікті қолданыстағы көрінісі; 10-бөлімдегі ерекшелікпен («жай чат-бот емес», «жай ақпарат базасы емес») — философияның теріске шығару арқылы дәлелденуі.
Бұл философиялық тұжырымның мәні тек декларативті емес — ол жобаның кез келген даму шешімін бағалау үшін нақты сынақ (test) ретінде қолданыла алады. Егер жаңа функция немесе өзгеріс тек ақпаратты сақтауды жақсартса, бірақ байланыс анықтауға немесе білім қалыптастыруға қызмет етпесе — ол функция MindRelay-дің философиясына толық сай келмейді деп саналуы мүмкін. Дәл осы принцип 13.4-тармақта («Күтілетін нәтижелер мен даму бағыттарының арақатынасы») практикалық түрде қолданылған болатын.
Жобаның авторы, идея иесі және жалғыз әзірлеушісі — Қалқөз Ернат.
Бұл құжат бойында бірнеше рет аталған факт — MindRelay команда немесе ұйым жасаған жоба емес, бір адамның қолымен, 2026 жылғы 6 маусымнан бастап (11.2-тармақ) қазіргі күнге дейін дербес жасалып келе жатқан жоба. Бұл жағдайдың жобаның бірнеше сипатына тікелей әсері бар, оларды осы құжатта әр жерде байқауға болады:
| Жалғыз әзірлеушінің салдары | Қай бөлімде көрсетілген |
|---|---|
| Архитектуралық таңдаулардың прагматизмі (Flask-тың жеңілдігі, фреймворксіз frontend) | 5.1, 6.1.2, 6.2.1-тармақтар |
| Дамудың жоғары қарқыны, бірақ құрылымдық қайта қараудың жиі қажет болуы | 11.5, 5.6-тармақтар |
| Жобаның автордың жеке қажеттілігінен туындауы (дислексия, мессенджерлерді біріктіру) | 11.2.2-тармақ |
| «Жоба иесі» санатының бірінші, негізгі Пайдаланушы болуы | 9.2.1-тармақ |
Автор жобада бірнеше рөлде бір мезгілде әрекет етеді: Әзірлеуші — барлық код, архитектура, сәулеттік шешім; Оператор — MindRelay Пайдалану шарттарында (MR-002) анықталған, Платформаны басқаратын тұлға; Бірінші Пайдаланушы — жүйенің бастапқы, өлшенетін дизайн-мақсаты болған нақты адам (9.2.1-тармақ); Куратор — «Боттан алу» функциясы арқылы (13.3.3-тармақ) диалогтарға тікелей араласа алатын, N.I.R.A.-ның шешімдерін бақылайтын тұлға.
Осы паспорт — жоба туралы жалпы, түсіндірмелі ақпарат беруге арналған құжат, сондықтан мұнда автордың толық заңдық-құқықтық мәртебесі, юрисдикциясы немесе ресми байланыс мәліметтерінің кестесі қайталанбайды. Бұл ақпараттың ресми, құқықтық күші бар нұсқасы мынада орналасқан:
MindRelay Пайдалану шарттарының (MR-002) 3.9-тармағы, «Оператор туралы мәліметтер»
Сол тармақта Оператордың толық аты-жөні, құқықтық мәртебесі (жеке тұлға), юрисдикциясы (Қазақстан Республикасы), электрондық поштасы және байланыс тілдері кестелік түрде, ресми тұжырыммен берілген.
Дәл осы Жоба паспортына (MR-008) қатысты сұрақтар, ескертулер немесе түзетулер болса, оларды жіберуге болатын мекенжай:
ernat.konirat@gmail.com
Дата вступления в силу: 6 августа 2026 года | последнее обновление: 6 августа 2026 года | версия: 2.0
Полное официальное название проекта — MindRelay. Название состоит из двух английских слов: Mind (разум, сознание, мысль) и Relay (эстафета, передача, ретрансляция). Это составное название точно отражает основную идею проекта — передавать информацию и мысль из одного места в другое, от одного человека к другому подобно «эстафете», причём в этом процессе не просто транспортировать её, а обрабатывать, связывать, обогащать её смысл. Слово «Relay» используется и в техническом значении (устройство, принимающее, усиливающее и ретранслирующее сигнал) — это отражает, что MindRelay выполняет ту же функцию: принимает информацию, обрабатывает (усиливает/обогащает), ретранслирует.
MindRelay — интеллектуальная информационная система, основанная на технологиях искусственного интеллекта. Это определение можно рассмотреть в трёх аспектах: «Информационная система» означает, что основная функция системы — работа с информацией: её приём, хранение, обработка, передача; «Интеллектуальная» означает, что эта работа осуществляется не механически, а посредством искусственного интеллекта, на основе понимания смысла; система представляет собой не одну программу, а единую экосистему из нескольких взаимосвязанных компонентов (ядро бота, панель управления, хранилище данных, внешние интеграции).
«Лицо» системы и компонент, непосредственно общающийся с Пользователем, — N.I.R.A. (Neural Intelligent Relay Assistant). Полная расшифровка названия:
| Буква | На английском | Значение |
|---|---|---|
| N | Neural | нейронный — основанный на технологии искусственного интеллекта/машинного обучения |
| I | Intelligent | интеллектуальный — отвечающий с пониманием, а не по простому сценарию |
| R | Relay | эстафета — созвучно названию MindRelay, функция передачи информации |
| A | Assistant | ассистент — конечная роль, служение человеку |
Соотношение между N.I.R.A. и MindRelay можно объяснить так: MindRelay — название всей системы (платформы), а N.I.R.A. — видимая Пользователю, говорящая часть этой платформы. Остальные части, такие как дашборд, хранилище данных, внешние интеграции, напрямую Пользователю не видны — они служат опосредованно, через N.I.R.A.
MindRelay в настоящее время является проектом, находящимся в активной разработке, и одновременно реально функционирует в промышленном (production) режиме — то есть это не просто прототип или демо-версия, а система, ежедневно используемая, общающаяся с реальными Пользователями в реальном времени, хранящая реальные данные. Эти две характеристики («в активной разработке» и «в промышленном режиме») не противоречат друг другу — проект непрерывно обновляется и дополняется даже в рабочем состоянии (подробнее — раздел 11, «История проекта»).
Автор, владелец идеи и единственный разработчик проекта — Калкоз Ернат. MindRelay — не проект, созданный командой или организацией: вся архитектура, код и содержание, от первоначальной идеи до сегодняшнего дня, созданы одним человеком (подробнее — раздел 15, «Автор и контакты»).
MindRelay использует две основные мессенджер-платформы для связи с Пользователями: WhatsApp и Telegram. Причина выбора именно этих двух — уже на этапе первоначальной идеи проекта (6 июня 2026, подробнее в разделе 11) эти два канала оказались наиболее используемыми и соответствующими собственной потребности автора. Слово «исходные» не означает, что этот список ограничен — как показано в разделе 13 («Планы на будущее»), система может расшириться и на другие каналы.
Конечная цель проекта MindRelay, одним предложением: отказаться от роли простого средства обмена сообщениями и стать платформой, которая собирает информацию, выявляет связи внутри неё, формирует на этой основе знание и со временем превращается в целостную интеллектуальную систему.
В этой формулировке можно выделить четыре стадии, вытекающие одна из другой: Сбор → Связывание → Формирование знания → Целостная интеллектуальная система.
Каждая стадия опирается на результат предыдущей — невозможно связывать несобранную информацию, невозможно извлечь знание из несвязанной информации, а без накопленного знания невозможна целостная интеллектуальная система. По этой причине рассматриваем цель, разделённую на шесть конкретных направлений — каждое из которых является звеном этой цепи.
Это — исходное, самое базовое звено цепи. MindRelay извлекает значимые данные из личных чатов, групповых чатов, голосовых сообщений и изображений. Важно, что процесс сбора представляет собой отбор, а не «сохранение всего»: система отличает случайные, малозначимые сообщения от значимых фактов (полное техническое описание — разделы 1–2 документа MR-003, философское обоснование — раздел 6 документа MR-006, «Информация, не включаемая в профиль»).
Собранная информация не остаётся изолированными друг от друга записями — система ищет между ними значимое отношение: связь между конкретным человеком и проектом, между темой и подтемой, либо скрытое сходство между двумя разными диалогами. Например, связь между «Ернатом» и проектом «MindRelay», либо взаимосвязь тем «Робототехника» и «Arduino» (полное разъяснение — раздел 7 документа MR-006, «Формирование связей»).
На основе накопленной и связанной информации система формирует обобщённые выводы и элементы знаний. Это — этап качественного скачка от собранных данных: отдельные факты («Ернат использует Arduino», «X часто спрашивали») превращаются в общее знание, обладающее самостоятельной ценностью, отделённое от конкретного диалога или Пользователя (полное разъяснение — раздел 9 документа MR-006, «Формирование элементов знаний»).
База знаний используется не только для хранения, но и для формирования новых идей, предложений или путей решения. Это осуществляется, в частности, посредством выявления закономерностей между схожими вопросами и ситуациями — система может вспомнить ранее встречавшиеся похожие проблемы и на их основе сформировать новое предложение.
MindRelay сохраняет предшествующий контекст конкретного Пользователя или темы, что устраняет необходимость повторного разъяснения при повторяющихся вопросах. Эта функция особенно важна с точки зрения пользовательского опыта — вместо того чтобы каждый раз начинать заново, N.I.R.A. «помнит» Пользователя (полное техническое описание — раздел 4 документа MR-006, «Понятие профилирования»).
Конечным результатом всех пяти целей, упомянутых в этом разделе, является своевременный, контекстно-соответствующий ответ через N.I.R.A. Эта цель сама по себе является последним, видимым результатом: для Пользователя весь сложный внутренний процесс (сбор, связывание, формирование знаний) внешне проявляется в виде одной вещи — точного и полезного ответа.
Эти шесть направлений не являются отдельными, независимыми друг от друга задачами — они функционируют как стадии последовательного процесса. Этот принцип подтверждён и в пункте 2.8 документа MR-006: «сбор, связывание, формирование, создание идей, сохранение контекста, повышение качества — не являются обособленными друг от друга, а представляют собой последовательные стадии единого процесса».
Практическое значение этого состоит в следующем: при оценке любой новой функции или изменения MindRelay можно проверить, соответствует ли она основной цели проекта, определив, какому из этих шести направлений она служит.
Если цель, описанная в разделе 2, показывает, что делает проект, то миссия выражает, для чего он это делает, какой ценности служит. Цель носит операционный характер (что нужно делать), а миссия — идеологический (для чего это нужно делать). Для MindRelay миссия сформулирована на двух уровнях: краткая, запоминающаяся версия и полностью раскрывающая её расширенная версия.
«Связывать информацию и превращать её в знание»
Хотя эта формулировка состоит всего из трёх слов, она охватывает всю суть проекта: «Информацию» — сырьё, исходный материал (диалоги, сообщения, факты); «связывать» — сам процесс, преобразующее действие (этап «связывания» в разделе 2); «превращать в знание» — конечный результат, переход сырья в новую, более высокую форму.
Эта краткая версия — «эталонная» формулировка, применяемая в случаях, когда проект нужно представить одним предложением (например, при первом знакомстве с партнёром).
«MindRelay — платформа, которая собирает информацию из цифровой жизни человека, находит и структурирует связи между ней и со временем превращает её в интеллектуальную систему знаний.»
Разберём эту расширенную версию по частям:
| Часть формулировки | Значение |
|---|---|
| «информация из цифровой жизни человека» | Источник — не реальная жизнь Пользователя, а его цифровые следы: сообщения, диалоги, медиа |
| «собирает» | Соответствует направлению «Сбор информации» (пункт 2.2.1) |
| «находит и структурирует связи» | Соответствует направлению «Связывание информации» (пункт 2.2.2) |
| «со временем» | Указывает, что это не одноразовое действие, а непрерывный, кумулятивный процесс |
| «превращает в интеллектуальную систему знаний» | Конечный результат — не просто база данных, а система, способная мыслить и развиваться |
Выражение «со временем» здесь особенно важно — оно указывает на не статичный, а динамичный характер миссии. MindRelay — не продукт, созданный один раз и остающийся в неизменном состоянии, а система, изменяющаяся и развивающаяся с каждым диалогом, с каждым новым Пользователем (эта идея подробнее раскрывается позже, в разделе 12, «Текущее состояние», и в разделе 15 документа MR-006, «Непрерывное развитие базы знаний»).
Эти два варианта не заменяют друг друга, у каждого своё место: Краткая формулировка — в рекламных материалах, однострочных презентациях, устном описании; Полная формулировка — в официальных документах (в настоящем паспорте), при необходимости более глубокого разъяснения инвестору или партнёру, при обсуждении в качестве основного направления проекта.
Обе формулировки составляют основу долгосрочного направления, описанного в разделе 4 («Видение / Vision») — если миссия отвечает на вопрос «что мы делаем сейчас», то видение отвечает на вопрос «что будет в будущем».
Любой человек, впервые открывший MindRelay сегодня, может внешне воспринять его как обычного персонального AI-ассистента — бота, общающегося через WhatsApp и Telegram, отвечающего на вопросы, запоминающего некоторую информацию. Это восприятие не является ошибочным, но оно неполное. Дело в том, что уже на этапе проектирования проекта, то есть ещё до написания первых функций (6 июня 2026, см. пункт 11.1), была заложена его долгосрочная траектория развития.
Это — основная причина того, почему раздел о видении важен: он раскрывает конечное направление, стоящее за текущим, видимым функционалом. Оценивать MindRelay без знания видения — то же самое, что видеть текущий размер дерева и не учитывать, до какой высоты оно способно вырасти.
В будущем предусмотрено расширение системы до трёх уровней. Эти уровни не заменяют друг друга — напротив, каждый строится поверх предыдущего, охватывая его в более широкой концепции:
Первый уровень — достижение MindRelay статуса не просто ассистента, а операционной системы, управляющей всеми знаниями Пользователя. Использование термина «операционная система» не случайно: подобно тому, как операционная система компьютера координирует и управляет всеми приложениями и процессами, MindRelay должна стать основой, управляющей из единого центра всеми информационными потоками Пользователя (различные мессенджеры, темы, проекты). На этом уровне MindRelay станет не просто приложением, а платформой, стоящей над всеми остальными инструментами.
Второй уровень смещает терминологический акцент с «операционной системы» на «память». На этом уровне MindRelay служит цифровым продолжением биологической памяти человека: каждый факт, каждая связь, каждая идея, которую человек забывает, но которая была важна, сохраняется в системе и воспроизводится при необходимости. Описанная в пункте 4.3 документа MR-006 текущая функция «N.I.R.A. „помнит“, что Пользователь говорил ранее» — это самое начальное, простое проявление именно этого будущего уровня. Особенность в том, что если текущая память ограничена диалогом одного Пользователя с N.I.R.A., то на уровне «Системы цифровой памяти» это должна быть целостная память, охватывающая всю цифровую жизнь человека.
Третий, наивысший уровень — концепция «второго мозга». Этот термин выражает широко применяемую в области управления знаниями идею: поскольку собственный мозг человека обладает ограниченной способностью к запоминанию и обработке, преодолеть это ограничение можно путём создания внешнего, цифрового «второго мозга». Однако в контексте MindRelay это не просто пассивное хранилище — это активный, способный мыслить партнёр: самостоятельно выявляет новые связи (раздел 8 документа MR-006, «Графы знаний»), предлагает идеи (пункт 2.2.4), даже самосовершенствуется (раздел 3 документа MR-005, «Цели хранения данных»).
Эти три уровня можно представить как ступенчатую лестницу: внизу — текущий персональный AI-ассистент (бот WhatsApp/Telegram), выше — Персональная операционная система знаний (превращение из одного ассистента в основу, координирующую всю информацию), ещё выше — Система цифровой памяти (расширение от отдельного диалога до всей цифровой жизни), а на самом верху — платформа «второго мозга» (превращение в активного, способного мыслить партнёра).
Каждый более высокий уровень стоит на функциональной основе более низкого, но качественно расширяет его. Это — объяснение того, почему проект ставит принцип «непрерывного развития» на первое место (раздел 8, «Основные принципы»): если развитие остановится, проект останется на первом уровне — простом боте.
С учётом этого будущего направления официальное определение проекта можно сформулировать следующим образом:
«MindRelay — система, которая сохраняет связи между людьми, идеями, проектами и знаниями и превращает информацию в долгосрочную интеллектуальную память.»
Полезно сравнить это определение с полной формулировкой миссии из раздела 3: миссия делает акцент на процессе («собирает... превращает»), а видение — на результате («сохраняет... память»); миссия отражает текущее действие, а видение — долгосрочную цель; в миссии ключевое слово «Платформа», а в видении — «Система».
Различие между ними не является принципиальным — миссия отвечает на вопрос «что мы делаем сейчас», а видение — на вопрос «что будет в конечном итоге». Оба являются двумя временными проекциями одного направления.
Значение этого раздела не только декларативное, но и практическое: конкретные направления развития, указанные в разделе 13 («Планы на будущее») — мобильная версия, расширение веб-панели, рост графа знаний — все они являются шагами, соответствующими определённым точкам этой трёхуровневой траектории. То есть видение — не список абстрактных мечтаний, а компас, направляющий конкретный план развития проекта.
Одним из первых вопросов, который нужно было решить при проектировании MindRelay, был вопрос о том, писать ли систему как единую, монолитную программу, или разделить её на несколько отдельных частей. Выбор пал на второе: MindRelay близка по принципу к микросервисной архитектуре, однако не является чистой микросервисной архитектурой — это промежуточное решение. В полной микросервисной системе каждый компонент может быть полностью независимым, вплоть до размещения на отдельном сервере. В MindRelay компоненты связаны между собой через HTTP/API и общую файловую систему, но в основном работают на одной машине, в тесной координации.
Причина выбора такого промежуточного подхода практическая: для единственного разработчика (пункт 1.5) управление полной микросервисной архитектурой — избыточная организационная нагрузка, а запись всего в один монолитный файл привела бы к трудночитаемому, опасному для изменения коду (конкретное доказательство — сам файл main.py превысил 8 500 строк, подробнее в пункте 11.5). Поэтому был выбран промежуточный путь: разделение по функциональной ответственности, но не по физическому расположению.
У этого выбора три конкретных преимущества: Независимое развитие — изменение в ядре бота не нарушает работу дашборда, и наоборот; Изоляция сбоя — если в мосте WhatsApp происходит сбой, связь через Telegram продолжается (ядро бота управляет обоими независимо); Технологическая свобода — каждый компонент может использовать наиболее подходящую для себя технологию (см. пункт 5.4 — почему мост WhatsApp написан не на Python, а на Node.js).
Это — центральный, координирующий компонент системы. Написан на языке Python, на основе веб-фреймворка Flask, работает на порту 5000. В его ответственность входит: приём всех сообщений, поступающих из WhatsApp и Telegram; анализ сообщения, определение его языка, обозначение категории (вопрос это, обращение или жалоба); полное управление логикой диалога — сценарии приветствия, основной беседы, прощания — всё находится здесь; вызов модулей в пакете core/ (см. пункт 5.2.2) и их координация друг с другом; установление прямой связи с провайдерами ИИ (OpenAI, Groq, Google) (подробнее — раздел 7); запись всех результатов в хранилище данных через obsidian/writer.py.
Текущий размер этого файла — примерно 8 500 строк (441 КБ), это самый большой и самый важный отдельный файл проекта. Такой размер сам по себе создаёт проблему — предупреждение об этом дано в пункте 5.6.
Если ядро бота (main.py) — это «сердце» системы, центр, обеспечивающий кровообращение, то пакет core/ — это её «мозг», то есть место, где сосредоточена конкретная интеллектуальная и вычислительная логика. Этот пакет состоит из нескольких самостоятельных модулей:
| Модуль | Класс/функция | Ответственность |
|---|---|---|
| agent.py | MindRelayAgent | Основная логика агента — центр «принятия решений» N.I.R.A. |
| pipeline.py | CognitivePipeline | Цепочка когнитивной обработки — последовательность шагов от получения сообщения до формирования ответа |
| knowledge_graph.py | — | Структура и логика графа знаний (полное разъяснение — раздел 8 документа MR-006) |
| learning.py | LearningSystem | Механизм самообучения системы (ежедневный журнал обучения, пункт 3.2 документа MR-005) |
| rag.py | ObsidianRAG | Retrieval-Augmented Generation — система поиска соответствующей информации в базе знаний |
| calendar_service.py | GoogleCalendarService | Служебный слой интеграции с Google Calendar |
| category.py | — | Логика разделения Пользователей на категории (раздел 5 документа MR-006) |
| scheduler.py | SchedulerService | Запускает запланированные задачи (например, ночное самотестирование) по наступлению времени |
| weekly_report.py | — | Формирование еженедельных итоговых отчётов |
Значение этого модульного разделения велико: для понимания различия между agent.py и pipeline.py — агент представляет собой логику, принимающую решение «что нужно делать», а pipeline представляет собой порядок выполнения этого решения конкретными шагами (приём сообщения → определение языка → загрузка контекста → отправка в ИИ → обработка ответа → сохранение).
Этот пакет состоит из двух файлов: telegram_bot.py и whatsapp_bot.py. Их задача — изолировать особенности, свойственные каждому каналу связи (формат сообщений, способ идентификации, ограничения API), от ядра бота. Благодаря этому разделению, например, свойственные каналу трудности, такие как проблема WhatsApp LID/номер (см. пункт 11.5), решаются только в этом одном файле, не затрагивая остальную систему.
Класс ObsidianWriter в файле writer.py — единственная точка связи системы с хранилищем данных (Obsidian). Это важное архитектурное решение: остальные части системы не пишут файлы напрямую, а все операции записи проходят через этот единый центр. Преимущество этого — обеспечение единообразия структуры файлов, правил именования (согласованных с разделами документа MR-006 о структуре файлов): если в будущем потребуется изменить структуру файлов, достаточно исправить только этот один файл.
Приложение Flask, полностью отдельное от ядра бота, работает на порту 8080. Причина отдельности важна: если бы панель управления работала в одном процессе с ядром бота, тяжёлая операция в дашборде (например, генерация большого отчёта) привела бы к замедлению ответа бота. Работа в качестве отдельного процесса устраняет этот риск. Текущий размер этого файла — примерно 4 600 строк. Полное функциональное описание дано в разделе 6 («Технологический стек») и в Условиях использования (MR-002).
Единственный компонент, написанный на Node.js (причина — в пункте 5.4). Использует библиотеку @whiskeysockets/baileys, которая устанавливает прямую, неофициальную связь (не через WhatsApp Business API) с протоколом WhatsApp Web. Авторизация осуществляется через QR-код — Пользователь (то есть в данном случае сам автор) сканирует QR-код приложением WhatsApp на телефоне, после чего сессия сохраняется, и повторное сканирование в следующий раз не требуется (данные сессии хранятся в папке auth_info/).
Этот пакет, состоящий из более чем 20 файлов JSON, сохраняет «не долгосрочное, но важное» состояние системы — например, список VIP-контактов, состояние открытых обращений (zapros), данные геймификации (квесты, статистика), историю трендов оценок, состояние предложений правил, последний результат ночного самотестирования. Эти файлы отличаются от хранилища данных Obsidian — если Obsidian хранит «содержательную» информацию (диалоги, профили, знания), то config/ хранит «операционное» состояние системы.
Этот пакет — компонент, предназначенный не для внутренней работы системы, а для взаимодействия с внешним миром: index.html, about.html, documents.html и соответствующие данной серии документов файлы doc-privacy.html, doc-terms.html, doc-retention.html, doc-liability.html, doc-ai-policy.html. Это — конкретное доказательство того, что MindRelay стремится быть не просто технической системой, а открытым, отчитывающимся перед своими Пользователями проектом (подробнее — раздел 8, «Основные принципы», принцип «Прозрачность»).
Покажем полный путь одного сообщения по шагам — с момента отправки Пользователем сообщения через WhatsApp до получения ответа:
Приём: сообщение достигает моста whatsapp/index.js от серверов WhatsApp (через библиотеку Baileys);
Отправка: мост отправляет сообщение в виде HTTP-запроса в ядро бота (main.py, порт 5000);
Предварительная обработка: ядро бота обрабатывает специфичное для WhatsApp форматирование через bots/whatsapp_bot.py (например, здесь решается проблема LID/номер);
Когнитивная обработка: сообщение передаётся в CognitivePipeline в core/pipeline.py, который определяет язык, загружает контекст из Obsidian через core/rag.py, обозначает категорию через core/category.py;
Принятие решения: MindRelayAgent в core/agent.py решает, что делать — отвечать напрямую или оформлять как обращение (zapros);
Вызов ИИ: в зависимости от выбранного действия запрос отправляется в цепочку провайдеров ИИ (раздел 7);
Запись: результат — новый факт, обновлённый профиль, запись диалога — записывается в хранилище данных через obsidian/writer.py;
Обратная отправка: сформированный ответ отправляется из ядра бота обратно в мост whatsapp/index.js, а затем через серверы WhatsApp достигает Пользователя.
В качестве параллельной ветви этой цепочки панель управления (dashboard/app.py) может в любой момент напрямую считывать результат этого процесса — обновлённые файлы Obsidian и файлы состояния config/, — поскольку она, будучи отдельным процессом, имеет доступ к той же общей файловой системе.
У читателя может возникнуть закономерный вопрос: почему вся система не написана на одном языке? Ответ — в принципе выбора инструмента, соответствующего каждой задаче. Наиболее стабильная, широко используемая библиотека, устанавливающая прямую, неофициальную связь с WhatsApp, — Baileys — предназначена для среды JavaScript/Node.js. Вместо того чтобы «переписывать» её на Python, было выбрано использовать готовое, испытанное решение в его собственной среде, лишь связав его с остальной Python-системой через HTTP. Это — конкретный пример преимущества «технологической свободы», упомянутого в пункте 5.1.
И ядро бота, и панель управления используют одно общее хранилище данных — файловую систему на основе Markdown, построенную на Obsidian, — вместо традиционной реляционной базы данных (MySQL/PostgreSQL). Полное обоснование и преимущества этого выбора подробно приведены в пункте 6.3 (Технологический стек) и в документах MR-003, MR-006.
В соответствии с принципом прозрачности (раздел 8), здесь следует отметить и текущий архитектурный недостаток системы: размер ядра бота (main.py) со временем вырос до 8 500 строк, что является очень большим объёмом для одного файла. В традиционной практике программной инженерии логика такого объёма обычно разделяется на несколько более мелких модулей. Это — естественное следствие быстрого, итеративного развития проекта (раздел 11) и одновременно одно из направлений будущего совершенствования (раздел 13).
Три основных вычислительных компонента MindRelay — ядро бота, панель управления и все модули пакета core/ — написаны на языке Python. У этого выбора несколько конкретных причин: совместимость с экосистемой искусственного интеллекта — у всех провайдеров ИИ, таких как OpenAI, Groq, Google Gemini, есть официальные клиентские библиотеки для Python; удобство работы с текстом — возможности Python по обработке текста и работе с файлами естественным образом подходят для работы с хранилищем данных на основе Obsidian; возможность быстрой разработки — для единственного разработчика простой синтаксис Python и обширная библиотечная база повышают скорость разработки.
В настоящее время в проекте используется версия Python 3.13.3, одна из последних стабильных версий языка.
Flask — веб-фреймворк, лежащий в основе двух главных HTTP-серверов системы (ядра бота и панели управления). Причина выбора Flask вместо «всё включено» фреймворков наподобие Django — его лёгкий, минималистичный характер: MindRelay не нужны сложные возможности, предлагаемые Django, такие как полный ORM, admin-панель, система аутентификации, поскольку в качестве базы данных используется не реляционная система, а файловое хранилище Obsidian (пункт 6.3).
Единственная основная backend-технология вне Python. Причина её использования полностью объяснена в пункте 5.4 — принадлежность библиотеки Baileys к среде JavaScript. Используется версия Node.js v24.16.0.
Встроенный в сам Flask сервер разработки (development server) предназначен только для тестирования, он не приспособлен для одновременной обработки множества запросов, для стабильной работы. Поэтому MindRelay в production-режиме (пункт 1.4) использует библиотеку waitress в качестве WSGI-сервера — она обеспечивает надёжную, многопоточную работу приложения Flask.
Интерфейс панели управления создан на основе HTML5, CSS3 и чистого (Vanilla) JavaScript — отдельный frontend-фреймворк, такой как React, Vue или Angular, не используется. У этого решения есть осознанное обоснование: лёгкость и скорость — интерфейс без фреймворка быстрее загружается в браузере; отсутствие этапа сборки — React/Vue обычно требуют процесса сборки, такого как npm run build; Vanilla JS позволяет без этого дополнительного шага сразу видеть результат, напрямую изменяя файл и обновляя браузер; простота для единственного разработчика — вместо освоения кривой обучения и экосистемы большого фреймворка, прямое использование известных, стандартных веб-технологий.
У этого выбора есть и обратная сторона — в крупных интерфейсах код Vanilla JS может стать неструктурированным, что перекликается с общими архитектурными ограничениями, упомянутыми в пункте 5.6.
Все статистические графики и диаграммы в панели управления (страница мониторинга, ежедневные/еженедельные тренды) строятся с помощью библиотеки Chart.js. Это — лёгкая, широко распространённая библиотека, работающая на основе HTML5 Canvas, поддерживающая основные типы диаграмм (donut, bar, line).
MindRelay использует не традиционную реляционную базу данных (MySQL, PostgreSQL, SQLite), а систему под названием Obsidian, изначально созданную для персонального управления знаниями, основанную на файлах Markdown. Это — одно из самых своеобразных архитектурных решений проекта, поэтому его обоснование стоит рассмотреть подробнее.
| Преимущество | Пояснение |
|---|---|
| Формат, читаемый человеком | Данные хранятся в виде обычных текстовых (.md) файлов — их можно читать напрямую любым текстовым редактором, без специального клиента базы данных |
| Естественная система связей | Собственный синтаксис [[wiki-link]] Obsidian позволяет устанавливать ссылки между файлами — это естественным образом сочетается с концепцией графа знаний (раздел 8 документа MR-006) |
| Независимость от сервера | База данных не требует отдельного серверного процесса — данные хранятся непосредственно в файловой системе, что упрощает резервное копирование до уровня простого копирования файлов |
| Гибкая структура | Нет жёсткого табличного (table/schema) ограничения — каждая папка Пользователя (пункт 4.2 документа MR-003) может иметь свободную внутреннюю структуру |
У этого выбора есть и последствия — сложные запросы (JOIN, агрегация), свойственные реляционным базам данных, невозможны или реализуются сложнее, а скорость поиска при большом объёме данных может быть ниже, чем у специально проиндексированной базы данных. Именно по этой причине в модуле core/rag.py создана специальная система ObsidianRAG — она служит дополнительным слоем для эффективного поиска информации в файлах Obsidian.
Полное техническое описание, структура файлов и порядок хранения приведены в документах MR-003 (Политика сбора, обработки и формирования знаний) и MR-006 (Политика базы знаний и профилирования).
Помимо описанного выше основного стека, MindRelay использует несколько специализированных внешних сервисов и библиотек, каждая из которых отвечает за конкретную функцию:
| Сервис/библиотека | Назначение | Контекст использования |
|---|---|---|
| Google Calendar API | Проверка расписания владельца | В режиме работы «По расписанию» N.I.R.A. автоматически определяет доступность Оператора по календарю (пункт 4.5 документа MR-002) |
| OpenAI Whisper | Преобразование голосовых сообщений в текст | Каждый раз, когда Пользователь отправляет голосовое сообщение, транскрипция осуществляется через этот сервис |
| OpenCV (cv2) | Извлечение кадра из видеофайлов | При получении видеосообщения система автоматически извлекает первый кадр и анализирует его через AI Vision |
| pypdf | Анализ PDF-документов | Если Пользователь отправляет файл PDF, его текстовое содержание извлекается через эту библиотеку |
| python-docx | Обработка документов Word | Для чтения и обработки документов в формате Word |
| Twilio | SMS / дополнительный канал связи | Испытан/подключён как дополнительный или альтернативный канал связи |
Каждая из этих интеграций составляет техническую основу «слоя обработки медиа» системы (пункт 3.6 документа MR-002, «Поддерживаемые виды контента») — обеспечивая, чтобы Пользователь мог отправлять не только текст, но и голос, изображение, видео, документ.
Способность MindRelay отвечать в корне зависит от внешних сервисов искусственного интеллекта — если провайдер ИИ недоступен, N.I.R.A. не сможет ответить. Если бы система зависела только от одного провайдера (например, только от OpenAI), любой временный сбой этого провайдера (отказ сервера, исчерпание квоты, техническое обслуживание) привёл бы к полной остановке всей системы MindRelay.
Чтобы избежать этого риска единой точки отказа (single point of failure), система использует не единую, а многоуровневую (fallback chain) структуру провайдеров ИИ. Логика этого подхода проста: если провайдер первого уровня недоступен, система автоматически переключается на второй уровень; если и он недоступен — на третий. Для Пользователя это переключение совершенно незаметно.
| Уровень | Провайдер | Роль и причина выбора |
|---|---|---|
| 1 (основной) | OpenAI (GPT-4o-mini) | Отличается способностью давать наиболее качественные, точные и контекстно-соответствующие ответы. Эта модель используется в повседневном, основном режиме работы. |
| 2 (резерв) | Groq (Llama 3.3 70B) | Задействуется при недоступности или превышении лимита OpenAI. Особенность — благодаря специальной вычислительной инфраструктуре Groq (LPU) скорость ответа значительно выше. |
| 3 (последний резерв) | Google Gemini (2.0 Flash-Lite) | Последняя сеть безопасности на случай недоступности обоих предыдущих уровней. |
Эта трёхступенчатая цепочка обеспечивает независимость системы от одного-единственного внешнего сервиса и гарантирует продолжение работы бота даже при временной недоступности любого из сервисов.
История функции анализа изображений — наглядный пример реального опыта принятия технических решений в проекте. Первоначально эта функция была реализована через Google Gemini Vision. Однако квота запросов бесплатного уровня Gemini исчерпалась достаточно быстро — это стало практическим доказательством ограниченности бесплатной квоты при реальной производственной нагрузке. После этого архитектура была полностью переведена на OpenAI Vision, и этот переход сохраняется до сих пор.
Это событие зафиксировано и как один из этапов развития, описанных в разделе 11 («История проекта») (пункт 11.5) — оно является доказательством того, что проект развивается не только по плану, но и путём адаптации к реально возникшим техническим ограничениям.
Меры безопасности при отправке данных провайдерам ИИ (конфиденциальность API-ключей, зашифрованный канал связи, отсутствие записи конфиденциальной информации в системных логах) подробно описаны не в настоящем паспорте, а специально в разделе 8 документа MR-007 (Политика безопасности) («Безопасность сторонних сервисов»). А то, как и с какой целью данные Пользователя передаются провайдерам ИИ, — в разделе 6 Политики конфиденциальности (MR-001).
Трёхуровневая цепочка, описанная в пунктах 7.1–7.3, — текущее положение дел, но оно не является постоянным. С учётом стремительного развития сферы технологий ИИ состав и порядок цепочки провайдеров может измениться в будущем (например, при выходе новой, более эффективной модели, или при изменении соотношения цены/качества существующих провайдеров). Это — ещё одно проявление принципа «непрерывного развития» системы, упомянутого в разделе 8.
Для правильного понимания этого раздела необходимо сначала установить одну важную границу: описанные здесь принципы — принципы проекта на продуктовом уровне, то есть отвечающие на вопрос, каким должен быть MindRelay в целом, какого направления придерживается. Эти принципы не следует путать с философией, касающейся хранения данных (она рассмотрена отдельно в пунктах 17.2 и 17.5 документа MR-005) — последняя охватывает узкий вопрос характера владения и судьбы хранения конкретных данных Пользователя, тогда как приведённый здесь перечень определяет целостное, общее направление и поведение проекта.
Поясним это различие на конкретном примере: принцип «Прозрачность» (пункт 8.2) означает, что архитектура и история развития проекта не скрываются (продуктовый уровень), а «принцип прозрачности» в документе MR-005 (пункт 16.5) означает, что Пользователь может в любое время запросить содержание своего профиля (уровень данных). Хотя оба называются «прозрачностью», каждый отвечает на другой вопрос.
Цель, архитектура и история развития проекта MindRelay не скрываются. Конкретное проявление этого принципа — сам настоящий документ (Паспорт проекта): проект открыто описывает свою внутреннюю структуру (раздел 5), реальную историю роста (раздел 11), даже архитектурные недостатки (пункт 5.6). Кроме того, наличие компонента trust_center/ (пункт 5.2.8) — доказательство реализации прозрачности на техническом уровне.
Защита данных Пользователя учитывается на каждом уровне проекта — от архитектурной изоляции (централизованный механизм записи в пункте 5.2.4) до структуры системных логов (пункт 7.4). Полная, техническая реализация этого принципа приведена в документе MR-007 (Политика безопасности).
Персональные данные используются только в согласованной с Пользователем, явной цели — не используются в рекламных, коммерческих целях продажи или для передачи третьим лицам. Полное правовое обоснование этого принципа приведено в документе MR-001 (Политика конфиденциальности).
Этот принцип, пожалуй, наиболее ярко характеризующая MindRelay черта. Проект не останавливается — как показано в разделе 11 («История проекта»), почти каждую неделю добавлялся новый функционал, и этот процесс продолжается до сих пор (раздел 12, «Текущее состояние»). Этот принцип напрямую связан с трёхуровневой траекторией развития, описанной в разделе 4 («Видение») — если развитие остановится, проект останется на уровне «Персонального AI-ассистента», не достигнув уровня «Персональной операционной системы знаний».
Приоритетным направлением считается не простое хранение информации, а извлечение из неё смысла и связей. Этот принцип — самый глубокий из шести направлений, описанных в разделе 2 («Цель проекта») — философская основа приоритета синтеза нового знания из данных, а не просто их сбора. На практическом уровне этот принцип полностью раскрыт технически и юридически в разделах 9 и 10 документа MR-006 («Формирование элементов знаний» и «Характер владения базой знаний»).
Построение единого, взаимосвязанного контекста, а не изолированных фактов — основной признак, отличающий MindRelay от обычного чат-бота (раздел 10, «Особенность проекта»). Этот принцип конкретно, технически реализован в концепции графа знаний (раздел 8 документа MR-006): отдельные связи со временем пересекаются друг с другом, превращаясь в многоуровневые, богатые по смыслу структуры.
Эти шесть принципов не являются изолированным друг от друга списком — они тесно взаимосвязаны. Например, пересечение принципов «Непрерывное развитие» (8.5) и «Прозрачность» (8.2) означает, что каждое изменение проекта не скрыто, а само развитие открыто документируется (через настоящий паспорт). Аналогично, «Формирование знаний» (8.6) и «Связывание информации» (8.7) — две соседние стадии последовательного процесса, описанного в разделе 2 (сбор → связывание → формирование знаний), поэтому эти два принципа не имеют полного смысла друг без друга.
Эта взаимосвязь не случайна — все шесть принципов, в конечном счёте, выражают разные грани одной основной идеи, сформулированной в разделе 3 («Миссия»), — «связывать информацию и превращать её в знание».
При описании целевой аудитории для MindRelay недостаточно одного списка, поскольку, как показано в разделе 4 («Видение»), проект следует рассматривать не только в текущем состоянии, но и в его долгосрочной траектории развития. Поэтому аудиторию также описываем, разделив на два конкретных временных слоя: текущую, реально существующую аудиторию и предполагаемую в будущем, ещё не сформировавшуюся аудиторию. Эти два слоя принципиально отличаются друг от друга — первый соответствует текущим техническим и организационным возможностям проекта, второй напрямую связан с уровнями развития из раздела 4.
Эту категорию важно отметить особо, поскольку MindRelay изначально (пункт 11.2, «История проекта») возник из личной потребности именно этого человека: преодоление дислексии, объединение всех мессенджеров, управление информацией и распорядком дня. Следовательно, автор — не просто тестировщик или администратор, а реальный пользователь, являвшийся исходной, первой целью проектирования системы. Это обстоятельство — то, чем MindRelay отличается от многих проектов: функции изначально создавались в ответ не на абстрактного «среднего пользователя», а на конкретную, измеримую личную потребность.
Помимо автора, физические лица, взаимодействующие с MindRelay, — это Пользователи, обращающиеся к N.I.R.A. через WhatsApp или Telegram, задающие свои вопросы, оставляющие обращения (zapros) (полное правовое определение — раздел 2 документа MR-002, «Термины и определения»). К этой категории, в частности, относятся клиенты, партнёры, знакомые, поддерживающие связь с автором.
N.I.R.A. может участвовать не только в личных диалогах, но и в групповых чатах (полное техническое описание — пункт 3.4 документа MR-002 и раздел 2 документа MR-003). В этом случае аудиторией является не отдельный человек, а небольшая группа или сообщество — характер взаимодействия здесь отличается от личного чата (например, N.I.R.A. по умолчанию не даёт публичного ответа в группе, только слушает).
Эти категории напрямую связаны с уровнями развития, описанными в разделе 4 — каждый следующий тип аудитории требует достижения системой соответствующего уровня.
Достижение MindRelay уровня «Персональной операционной системы знаний» (пункт 4.2.1) — предпосылка превращения её в систему, способную обслуживать не одного человека, а целую организацию. Это расширение уже предусмотрено в пункте 1.10 Условий использования MindRelay (MR-002): «Платформа в будущем может предоставляться третьим лицам для использования от своего имени и в своих целях», где понятие «владелец» соответствует именно этой организационной аудитории.
Естественная сфера применения уровня «Системы цифровой памяти» (пункт 4.2.2) — образование. Связывание учебных материалов, структуры курсов, вопросов и ответов учащихся и их структурирование в виде графа знаний (раздел 8 документа MR-006) может представлять особую ценность для образовательных проектов.
Уровень платформы «второго мозга» (пункт 4.2.3) напрямую соответствует природе исследовательской работы: исследователи часто ищут связи между большим объёмом информации, источников, идей — именно это является основной целью MindRelay (раздел 2). Для исследовательских групп система может стать инструментом формирования общей базы знаний.
Расширение аудитории от индивидуального пользователя до организаций — прямое следствие принципа «Непрерывное развитие», описанного в разделе 8. Но это расширение должно быть уравновешено принципом «Конфиденциальность» в пункте 8.4 — в частности, в пункте 1.10 документа MR-002 прямо указано, что каждый «владелец» является самостоятельным оператором в отношении своих Пользователей, самостоятельно несёт ответственность за обработку персональных данных. Следовательно, расширение аудитории требует соответствующего разделения ответственности — этот вопрос будет более подробно урегулирован в соответствующих правовых документах по мере фактической реализации новых категорий.
Человек, впервые увидевший MindRelay со стороны, может легко принять его за «ещё одного WhatsApp-бота» — сейчас на рынке существуют десятки, даже сотни внешне похожих чат-ботов. Поэтому необходимо показать точными, конкретными доказательствами, чем именно отличается проект — не общими словами «мы особенные», а конкретным отличием на техническом и архитектурном уровне.
Наиболее наглядный способ показать особенность — сопоставить, чем MindRelay НЕ является и чем ЯВЛЯЕТСЯ:
| MindRelay — НЕ | MindRelay — ЭТО |
|---|---|
| ❌ Обычный чат-бот | ✅ Система формирования знаний |
| ❌ Обычная база данных | ✅ Система выявления связей |
| ✅ Интеллектуальный помощник |
Структура этой таблицы не случайна: левый столбец — две категории, внешне похожие на MindRelay, но в основе своей другие («чат-бот» и «база данных»), а правый столбец — три конкретных характеристики, показывающие, чем именно MindRelay отличается от каждой из этих двух категорий.
Обычный чат-бот работает по определённому сценарию: приходит вопрос → даётся заранее записанный ответ или ответ по ограниченной логике → диалог завершается, фактически не оставляя следа. MindRelay отличается от этого тремя конкретными путями: контекст сохраняется (раздел 4 документа MR-006) — хотя диалог завершён, полученный из него факт и связь не теряются; ответ не статичен — N.I.R.A. может дать разный, адаптированный к контексту ответ на один и тот же вопрос в разное время (пункт 8.2.4 документа MR-002); развивается вне диалога — механизм самообучения системы (раздел 3 документа MR-005) работает и вне диалога, даже ночью.
Обычная база данных (например, обычная база данных или хранилище документов) хранит данные, но самостоятельно не ищет связи между ними — поиск осуществляется только по конкретному запросу, пассивно. MindRelay отличается от этого активной, самостоятельной способностью выявления связей: автоматическое выявление связей (пункт 7.8 документа MR-006) — «связи выявляются... автоматически, с помощью искусственного интеллекта, отдельного подтверждения со стороны Пользователя не требуется»; многоуровневая структура (раздел 8 документа MR-006, «Графы знаний») — отдельные связи со временем пересекаются друг с другом, превращаясь в многослойные цепочки, такие как «Ернат → MindRelay → N.I.R.A. → Arduino → Робототехника → проект „Фаэтон“»; изменение характера владения (раздел 10 документа MR-006) — обработанная информация отделяется от исходного источника, приобретая новую, самостоятельную ценность, — свойство, полностью отсутствующее в обычной базе данных.
Все приведённые выше доказательства основаны на трёх конкретных разделах, на которые специально указываем читателю, желающему изучить их подробнее: раздел 5 (в настоящем документе, «Архитектура системы») — многообразие компонентов: для простого обмена сообщениями не понадобились бы девять модулей пакета core/, граф знаний, система RAG; раздел 7 (в настоящем документе, «Многоуровневая структура провайдеров ИИ») — для простого сценарного бота трёхуровневая fallback-цепочка была бы избыточной, это — признак инвестиции в глубокую, устойчивую интеллектуальную функцию; разделы 8 и 10 документа MR-006 («Графы знаний» и «Характер владения базой знаний») — эти два раздела составляют самый глубокий, самый концептуальный слой проекта.
Три особенности, описанные в этом разделе («не обычный чат-бот», «не обычная база данных», «интеллектуальный помощник»), не случайны — они являются прямым техническим проявлением миссии, сформулированной в разделе 3 («связывать информацию и превращать её в знание»). Если бы проект был только чат-ботом или только базой данных, миссия не была бы выполнена: чат-бот не связывает, база данных не превращает в знание. Именно одновременное превосходство над этими двумя ограничениями — структурная основа своеобразия MindRelay.
Все даты, события и прямые цитаты, приведённые в этом разделе, не являются вымышленными или обобщёнными — они основаны на реально проверенном источнике: реальной истории переписки на начальных этапах проекта, и результате запущенного автором локально, предназначенного только для чтения инвентаризационного скрипта (реальные даты изменения и объёмы файлов). Эта методологическая чистота важна, поскольку «история» многих проектов впоследствии вспоминается и записывается идеализированно — тогда как приведённая здесь хронология напрямую подтверждена архивными данными.
Проект начался 6 июня 2026 года с простого предложения автора: «Давай жана проект бастайык» («Давай начнём новый проект»). Когда был задан вопрос о том, что именно нужно сделать, ответ был: «ии агент жасағым келеді» («хочу сделать ИИ-агента»). Это была исходная точка на уровне общей идеи, где ещё не были определены ни название проекта, ни архитектура, ни конкретные функции.
В ходе последующего уточнения запрос автора был разделён на три конкретные, отличающиеся друг от друга задачи:
| № | Задача | Исходная причина |
|---|---|---|
| 1 | Преодоление дислексии | Потребность автора автоматически исправлять собственные ошибки письма на трёх языках (казахском, русском, английском) — самый личный, самый человеческий мотив проекта |
| 2 | Объединение каналов связи | Управление сообщениями из всех мессенджеров из одного места, ответ от имени автора |
| 3 | Сбор информации и управление распорядком дня | Обработка поступающих от людей запросов и доведение их до сведения автора |
Объединение этих трёх задач важно: MindRelay изначально возник не как инструмент для решения одной-единственной проблемы, а как идея объединения трёх различных личных потребностей в одной системе. Именно этот принцип «объединения» впоследствии развился до основной миссии проекта («связывать информацию и превращать её в знание», раздел 3).
Уже в той же сессии было принято несколько обоснованных технических решений: Платформы — WhatsApp и Telegram (выбраны обе, а не одна); Хранилище данных — Obsidian, в локальном (local) режиме — облачные альтернативы не рассматривались; Первоначальный план развития — разделён на четыре этапа: Этап 1 — Telegram-бот + исправление дислексии; Этап 2 — интеграция WhatsApp; Этап 3 — автоматическая запись в Obsidian; Этап 4 — управление распорядком дня.
Интересно сравнить этот первоначальный четырёхэтапный план с реальной историей развития в пункте 11.5: если план был линейным (последовательным), то реальное развитие шло многонаправленно и значительно быстрее — это явление, свойственное любому программному проекту.
Второй день проекта — особый показатель темпа развития. В течение одного дня были практически одновременно созданы: первая версия панели управления (dashboard); интеграция Google Calendar; первоначальная версия графа знаний (файл knowledge_graph.py); страница чатов.
Этот «взрывной» рост не случаен — он показывает, что первоначальная идея автора была достаточно конкретной и полностью продуманной, поэтому процесс её превращения в код не слишком замедлился. Тем не менее, такое быстрое начальное строительство также создало места, требовавшие структурного пересмотра на последующих этапах (пункт 11.5) (например, «полная реструктуризация истории чатов»).
Выбор имени ассистента — самый запоминающийся момент проекта, показывающий, когда появилась его «душа». Этот процесс прошёл несколько конкретных этапов:
Казахские варианты: «Жарқын» (в значении «светлый, умный»), «Сенім» — но они не соответствовали предпочтениям автора;
Международное направление «ARIA»: была предложена полная расшифровка Artificial Relay Intelligence Assistant;
Запрос на уточнение: автор уточнил «в таком же духе, что и ARIA, но по-другому» — это означало необходимость искать новый смысл, сохраняя тот же звуковой образец;
Варианты в формате A-R-I-A: были предложены MIRA (Mind Intelligent Relay Assistant), VERA (Virtual Ernat Relay Assistant), KIRA (Knowledge Intelligent Relay Assistant), NIRA (Neural Intelligent Relay Assistant);
Окончательный выбор: автор принял решение — «NIRA болсын аты» («пусть имя будет NIRA»).
Название NIRA впоследствии было закреплено в официальных документах в виде N.I.R.A. (с точками) (см. пункт 1.3). Часть Relay в этом названии созвучна названию MindRelay, и это не случайно: хотя имя было придумано как для отдельной личности, было важно, чтобы оно оставалось связанным с более крупным брендом системы — MindRelay.
После выбора имени, сразу в той же сессии, был определён и характер Ассистента: использующий эмодзи; говорящий в дружеском тоне; дающий короткие ответы, но открыто сообщающий, если Пользователь хочет более полную информацию; тёплый и заботливый; продолжающий на языке, на котором начался диалог, а при затруднении в определении языка — уточняющий у Пользователя, на каком языке он хочет общаться; при непонимании — не выдумывающий ничего от себя, а задающий уточняющий вопрос.
Последний пункт этой характеристики — требование «ничего не выдумывать» — впоследствии напрямую перекликается с принципом, юридически закреплённым в пункте 8.7 Условий использования MindRelay (MR-002) («Ограничения точности и достоверности»).
Этот период — самая интенсивная фаза развития проекта, подтверждённая не только качественным описанием, но и конкретным численным доказательством. Данные, полученные путём измерения объёма ядра бота (main.py):
| Дата | Объём main.py | Прирост от предыдущего замера |
|---|---|---|
| 23 июня 2026 | 2 692 строки | — (исходный замер) |
| 27 июня 2026 | 2 796 строк | +104 строки (за 4 дня) |
| 29 июня 2026 | 3 416 строк | +620 строк (за 2 дня) |
| 7 июля 2026 | 4 315 строк | +899 строк (за 8 дней) |
| 9 июля 2026 | 5 140 строк | +825 строк (за 2 дня) |
| 14 июля 2026 | 6 282 строки | +1 142 строки (за 5 дней) |
Закономерность, наблюдаемая в этой таблице, — темп роста не постоянный, а волнообразный: в некоторые двух-трёхдневные периоды добавлялись сотни строк (например, 27→29 июня), в другие — рост замедлялся. Это — явление, свойственное ритму работы индивидуального разработчика, а также каждый большой скачок, как правило, совпадает с добавлением одной крупной функции.
Совершенствование контекста диалога и системы памяти. В первоначальной версии N.I.R.A. отвечала на каждое сообщение отдельно, «забывая» предыдущую часть диалога — это был недостаток, напрямую противоречащий основной цели MindRelay («сохранение контекста», пункт 2.2.5). В качестве исправления была создана система, в которой последние 5 сообщений сохраняются полностью, а более ранние — в виде сокращённого через ИИ вывода.
«Скрытая миссия» — система сбора информации. В соответствии с конкретным требованием автора: «пусть бот не только отвечает, но и собирает информацию о людях, развивая базу знаний», был создан механизм, автоматически извлекающий факты из диалога и структурированно записывающий их в структуру Obsidian (Контакты/Категория/Имя). Это означает, что основное техническое ядро текущего документа MR-003 было заложено именно в этот период.
Добавление поддержки медиа. Бот был расширен таким образом, чтобы принимать не только текст, но и голосовые сообщения, изображения, видео, документы. Именно в этот период произошёл переход Google Gemini Vision → OpenAI Vision, описанный в пункте 7.3.
Создание основных страниц Dashboard. Были спроектированы и запрограммированы основные страницы, такие как Мониторинг, Отчёт бота, Управление ботом — именно тогда была заложена функциональная основа панели управления, описанная в пункте 5.2.5.
Решение проблемы WhatsApp LID/номер. При тестировании функционала отправки сообщений различие между внутренним идентификатором WhatsApp (LID) и реальным номером телефона привело к многочисленным ошибкам — сообщения не доходили до некоторых контактов. Эта проблема была решена путём добавления логики, автоматически определяющей формат номера и выбирающей соответствующий формат.
Полная реструктуризация истории чатов. Первоначальная версия читала только из /api/inbox и не могла корректно отображать имена контактов — это, возможно, следствие «взрывного» быстрого строительства, описанного в пункте 11.3, поскольку быстро созданные первые версии часто впоследствии требуют полного пересмотра.
В этот день проект, отдельно от технического развития, начал систематически создавать юридически-доверительную документацию. Последовательно были опубликованы: Политика конфиденциальности (MR-001) → Условия использования (MR-002) → Политика сбора, обработки и формирования знаний (MR-003) → Политика хранения и удаления данных (MR-005) → Политика базы знаний и профилирования (MR-006) → Политика безопасности (MR-007) → Паспорт проекта (MR-008) — настоящий документ.
Значение этого периода велико: он означает переход проекта от статуса просто «работающего кода» к статусу «отчитывающегося, открытого проекта» (конкретная реализация принципа «Прозрачность» из пункта 8.2). Номер MR-004 (вероятно, «Ограничение ответственности») был намеренно оставлен свободным — считается, что в настоящее время он охватывается разделом 10 ToS, и как отдельный документ отложен на будущее.
Ядро бота достигло 8 583 строк (441 КБ). По сравнению с исходной точкой в пункте 11.2 (ноль на 6 июня), рост составил более чем стократный примерно за два месяца. Тем не менее, этот численный рост породил и архитектурное ограничение, упомянутое в пункте 5.6, — достижение одним файлом такого объёма признано вопросом, требующим структурного совершенствования.
В период со 2 июня по 2 июля 2026 года, точно в то же время, что и MindRelay, автор реализовал дополнительный, физический проект под названием Faethon — сенсорный интеллектуальный светильник на основе Arduino и RGB-светодиодов, управляемый жестами рук. Само название взято из древнегреческой мифологии, от Фаэтона («сияющий, излучающий свет»).
Этот проект отмечен как «Завершён», однако его значение для MindRelay не утрачено — напротив, его название стало самым наглядным примером концепции графа знаний MindRelay: «Ернат → MindRelay → N.I.R.A. → Arduino → Робототехника → проект „Фаэтон“» (пункт 8.2.2 документа MR-006).
Это — не просто вымышленная иллюстрация, а реальное отражение реального, параллельно созданного автором второго проекта, а также самопоказательный пример способности MindRelay «выявлять связи» (пункт 10.4): система берёт свои примеры и из реальной жизни автора.
| Дата | Событие |
|---|---|
| 6 июня | Проект начался (определены три мотивации) |
| 7 июня | Взрывной первый день (dashboard, calendar, graph) |
| 2 июня — 2 июля | Проект Faethon (параллельный, независимый) |
| 11 июня | Добавлена система прощания |
| 14 июня | Присвоение имени: N.I.R.A. + определён характер |
| 23 июня | main.py: 2 692 строки |
| 29 июня | main.py: 3 416 строк |
| 7 июля | main.py: 4 315 строк |
| 9 июля | main.py: 5 140 строк |
| 14 июля | main.py: 6 282 строки |
| 1 августа | Начат Trust Center (с MR-001) |
| 1–2 августа | main.py: 8 583 строки (текущий объём) |
| 6 августа | Завершены MR-006, MR-007, MR-008 (сегодня) |
MindRelay в настоящее время (6 августа 2026 года) является полностью работающей системой, находящейся в промышленном режиме (в соответствии со статусом, указанным в пункте 1.4). Это не проект теоретического или демонстрационного характера: бот в реальном времени общается с клиентами через WhatsApp и Telegram, обрабатывает поступающую от них информацию, а автор через панель управления может напрямую контролировать весь этот процесс и при необходимости вмешиваться.
Чтобы раскрыть конкретное содержание определения «полностью работающая», стоит рассмотреть текущее состояние каждой части системы по отдельности.
Все основные страницы панели управления (dashboard/app.py), описанной в разделе 5 («Архитектура системы»), полностью прошли тестирование и стабильно работают:
| Страница | Функция |
|---|---|
| Дашборд | Отображение общей статистики и текущего состояния системы одним взглядом |
| Мониторинг | Подробное наблюдение за диалогами, оценками, активностью |
| Отчёт бота | Итоговый отчёт о качестве работы бота |
| Управление ботом | Прямое управление ботом — изменение режимов, отправка сообщений, настройка параметров |
| История чатов | Просмотр и поиск истории всех диалогов |
| База Obsidian | Просмотр хранилища данных непосредственно через веб-интерфейс |
Утверждение о том, что каждая из этих страниц «прошла тестирование», не случайно — как описано в пункте 11.5, некоторые страницы (например, История чатов) не работали полностью в первоначальной версии и впоследствии потребовали полной реструктуризации. Следовательно, «текущая стабильность» — результат не только добавления новой функциональности, но и исправления обнаруженных недостатков.
В MindRelay, помимо основного, служебного функционала, внедрён и дополнительный слой геймификации. Этот слой включает: RPG-статистику — отображение определённых показателей системы или Пользователя в виде статистики в стиле ролевой игры; систему квестов/навыков — механизм заданий и развития навыков, направленных на достижение определённых целей; систему XP/уровней — показатель прогресса на основе очков опыта и уровней; достижения (achievements) — звания или значки, присваиваемые при достижении определённых рубежей.
Наличие этого слоя — проявление того, что MindRelay стремится сделать пользовательский опыт (в том числе опыт самого автора) не просто «сухим» функциональным инструментом, а интересным и мотивирующим. Элементы геймификации не противоречат напрямую ни одному из принципов, упомянутых в разделе 8, а, напротив, служат ежедневным мотивационным инструментом принципа «Непрерывное развитие» (пункт 8.5).
Одна важная особенность MindRelay, отличающая её от других обычных чат-ботов (раздел 10), — наличие механизмов, развивающихся самостоятельно, вне диалога. Эти механизмы в настоящее время активно работают: ночное самотестирование — система в определённый период времени (ночью) пересматривает свои прежние ответы и оценивает их качество; система предложения правил — система делает выводы из собственного опыта и предлагает новые правила поведения (эти предложения не вступают в силу автоматически, они требуют утверждения Оператором); самостоятельное расширение тем — самостоятельное распознавание новых, ранее не определённых тем и их добавление в граф знаний; отслеживание тренда оценок — наблюдение за тем, как изменяются со временем оценки, полученные от Пользователей, выявление тенденции; автоматическое формирование FAQ — выявление часто задаваемых вопросов и создание базы готовых ответов на них.
Этот перечень более подробно, технически и юридически описан в документах MR-003 (Политика сбора, обработки и формирования знаний) и MR-006 (Политика базы знаний и профилирования) — в частности, то, как эти механизмы работают при сохранении конфиденциальности данных Пользователя (например, анонимизация элементов знаний, пункт 9.8.2 документа MR-006), полностью раскрыто в этих документах.
Три уровня, описанные в этом разделе, — основной функционал (12.2), дополнительный слой опыта (12.3), и механизмы саморазвития (12.4) — вместе показывают, где именно сейчас находится MindRelay на пути от уровня «Персонального AI-ассистента» к уровню «Персональной операционной системы знаний», описанному в разделе 4: основной функционал полностью стабилизирован, а самостоятельное развитие системы и способность выявления связей (граф знаний, самосовершенствование) активны, но всё ещё находятся в процессе становления.
Этот раздел отвечает на два взаимосвязанных, но по сути различных вопроса: для чего мы делаем этот проект (ожидаемые результаты — относящиеся к идеальной, конечной цели) и что конкретно мы делаем (направления развития — конкретно запланированные шаги в ближайшем будущем). Первый напрямую перекликается с шестью направлениями из раздела 2 («Цель проекта»), второй вырастает из конкретной технической основы, описанной в разделе 12 («Текущее состояние»).
Этот перечень — конечные критерии, по которым измеряется успешность проекта MindRelay. Каждый напрямую связан с определённой целью из раздела 2:
| Ожидаемый результат | Соответствующая цель из раздела 2 |
|---|---|
| Структурирование информации | «Сбор информации» (пункт 2.2.1) |
| Сохранение контекста | «Сохранение контекста» (пункт 2.2.5) |
| Формирование знаний | «Формирование знаний» (пункт 2.2.3) |
| Сокращение повторяющихся вопросов | Практическое следствие «Сохранения контекста» и «Оказания интеллектуальной помощи» |
| Развитие идей | «Развитие идей» (пункт 2.2.4) |
Закономерность, видимая в этой таблице, — ожидаемые результаты не являются новым, отдельным списком, они представляют собой измеримую, проверяемую версию целей, сформулированных в разделе 2. Например, «Сокращение повторяющихся вопросов» — не абстрактная идея, а показатель, который можно фактически проверить: если MindRelay работает хорошо, N.I.R.A. не должна повторно спрашивать у Пользователя ранее предоставленную информацию (подробнее — пункт 4.5 документа MR-006, «Сокращение повторяющихся вопросов»).
Этот перечень, напротив, представляет собой конкретные технические шаги на ближайшее будущее. Рассмотрим каждый по отдельности.
В настоящее время панель управления (пункт 5.2.5) доступна только через веб-браузер. Отсутствие мобильной версии ограничивает возможность автора (или будущих организационных Пользователей, пункт 9.3.1) контролировать систему в пути, вне компьютера. Система push-уведомлений напрямую связана с этим — она нужна для того, чтобы автор был немедленно проинформирован при значимом событии (например, новом обращении или предупреждении о безопасности, пункт 10.5 документа MR-007).
Как описано в пункте 6.4, в настоящее время видеофайлы анализируются методом извлечения одного кадра через OpenCV. Это упрощённый подход, поскольку один кадр не может передать полное содержание видео. Планируемое расширение идёт по двум направлениям: получение нескольких кадров (охват различных моментов видео) и транскрипция голоса (преобразование звуковой дорожки видео в текст также через OpenAI Whisper). При более полной реализации этого улучшения видеосообщение будет обрабатываться так же полно, как изображение и голосовое сообщение.
Эта функция — право Оператора в любое время лично подключиться к диалогу и отвечать вместо N.I.R.A. (полное правовое обоснование — пункт 4.4 документа MR-002, «Участие Оператора»). Технически эта функция реализована в пакете config/ (manual_takeover.json) и в ядре бота, но она ещё не полностью протестирована и остаётся областью, требующей совершенствования стабильности.
Для достижения 1-го уровня («Персональная операционная система знаний») трёхуровневой траектории развития, описанной в разделе 4 («Видение»), панель управления должна превратиться из интерфейса, просто показывающего статистику, в реальный центр управления. Это направление — процесс углубления, расширения и дополнения новыми возможностями текущего функционала Dashboard (пункт 12.2).
Шаг на пути к 5-му уровню («Расширенная экосистема») из раздела 4. В настоящее время граф знаний работает в основном в рамках триады человек-проект-тема (раздел 7 документа MR-006); расширение означает добавление в эту структуру новых типов узлов, более глубоких уровней связей.
Важно наглядно показать связь между этими двумя перечнями: направления развития (13.3) — средства достижения ожидаемых результатов (13.2), а не самоцель. Например, «Расширение анализа видеофайлов» (13.3.2) не является самоцелью — оно служит конечному результату «Структурирование информации» (13.2), поскольку чем полнее проанализировано видео, тем точнее структурированная информация получается.
С учётом этого принципа, вопрос, применяемый при оценке любого нового направления развития, таков: какому из пяти ожидаемых результатов в пункте 13.2 служит этот шаг? Если ответ не найден, это направление, возможно, отклоняется от основной миссии MindRelay (раздел 3).
Расположение этого раздела ближе к концу документа не случайно — раздел о философии, как правило, служит итоговым выводом, объединяющим и лежащим в основе всех предыдущих разделов (цель, миссия, видение, архитектура, история, текущее состояние, планы на будущее). Иными словами, если разделы 2–13 отвечают на вопросы «что» и «как», то этот раздел отвечает на вопрос «почему в конечном счёте именно так».
Примечание, упомянутое в разделе 8 («Основные принципы»), необходимо здесь подтвердить снова, теперь более чёткой формулировкой: это — продуктовая философия проекта. В пункте 17.2 документа MR-005 рассмотрена совершенно отдельная, философия данных — она разъясняет баланс владения между Пользователем и MindRelay: Пользователь обладает правом на свою исходную информацию, а MindRelay — правом на обобщённое знание, сформировавшееся в результате обработки этой информации (полное разъяснение — раздел 10 документа MR-006, «Характер владения базой знаний»).
Чтобы не путать эти две философии, чётко разграничим, на какой вопрос отвечает каждая из них:
| Продуктовая философия (настоящий раздел) | Философия данных (MR-005 §17.2) | |
|---|---|---|
| Вопрос | Для чего существует MindRelay? | Какое право у Пользователя и системы на данные? |
| Содержание | Суть связывания информации и формирования знаний | Баланс владения, пределы права на удаление |
| Сфера применения | Общее направление, миссия проекта | Конкретные правовые/технические вопросы |
«Цель MindRelay — не простое хранение информации. Проект направлен на выявление связей между информацией и формирование на их основе нового знания, понимания и идей.»
Разберём эту формулировку по частям — у каждого слова есть свой вес. «не простое хранение информации» — важно, что формулировка начинается с отрицания: философия прежде всего чётко заявляет, чего она хочет избежать — MindRelay отказывается быть пассивным архивом, «хранилищем данных». «выявление связей» — этот глагол дан в активном, ищущем характере, а не «сохраняет» или «собирает» — этот выбор слов точно соответствует механизму автоматического выявления связей, описанному в пункте 7.8 документа MR-006. «формирование нового знания, понимания и идей» — это словосочетание сопоставляет три отдельных понятия: знание (системный, структурированный факт), понимание (более глубокий, контекстный смысл) и идеи (новое, синтезированное предложение).
Эта философская формулировка не изолированное предложение — это узел одной нити, проходящей от начала до конца настоящего документа: с миссией в разделе 3 («связывать информацию и превращать её в знание») — практически та же идея, только повторённая в более глубокой, разъяснительной форме; с видением в разделе 4 (платформа «второго мозга») — эта философия обосновывает, для чего нужен тот далёкий будущий уровень; с принципами в разделе 8 («Формирование знаний», «Связывание информации») — операционное, повседневное проявление этой философии; с особенностью в разделе 10 («не обычный чат-бот», «не обычная база данных») — доказательство философии через отрицание.
Значение этой философской формулировки не только декларативное — она может применяться как конкретный тест для оценки любого решения о развитии проекта. Если новая функция или изменение улучшает лишь хранение информации, но не служит выявлению связей или формированию знаний — эта функция может считаться не полностью соответствующей философии MindRelay. Именно этот принцип был практически применён в пункте 13.4 («Соотношение ожидаемых результатов и направлений развития»).
Автор, владелец идеи и единственный разработчик проекта — Калкоз Ернат.
Факт, упомянутый в этом документе несколько раз, — MindRelay не проект, созданный командой или организацией, а проект, самостоятельно создаваемый одним человеком, с 6 июня 2026 года (пункт 11.2) по сегодняшний день. Это обстоятельство напрямую влияет на несколько характеристик проекта, которые можно заметить в разных местах настоящего документа:
| Следствие единственного разработчика | В каком разделе показано |
|---|---|
| Прагматизм архитектурных решений (лёгкость Flask, frontend без фреймворка) | пункты 5.1, 6.1.2, 6.2.1 |
| Высокий темп развития, но частая необходимость структурного пересмотра | пункты 11.5, 5.6 |
| Возникновение проекта из личной потребности автора (дислексия, объединение мессенджеров) | пункт 11.2.2 |
| Категория «владелец проекта» как первый, основной Пользователь | пункт 9.2.1 |
Автор одновременно выступает в проекте в нескольких ролях: Разработчик — весь код, архитектура, архитектурные решения; Оператор — лицо, управляющее Платформой, определённое в Условиях использования MindRelay (MR-002); Первый Пользователь — реальный человек, являвшийся исходной, измеримой целью проектирования системы (пункт 9.2.1); Куратор — лицо, способное напрямую вмешиваться в диалоги через функцию «перехвата от бота» (пункт 13.3.3), контролирующее решения N.I.R.A.
Настоящий паспорт — документ, предназначенный для предоставления общей, разъяснительной информации о проекте, поэтому здесь не повторяется полный правовой статус автора, юрисдикция или таблица официальных контактных данных. Официальная, имеющая правовую силу версия этой информации расположена здесь:
Пункт 3.9 Условий использования MindRelay (MR-002), «Сведения об Операторе»
В этом пункте полное имя Оператора, правовой статус (физическое лицо), юрисдикция (Республика Казахстан), электронная почта и языки общения приведены в табличной форме, официальной формулировкой.
Вопросы, замечания или исправления, касающиеся именно настоящего Паспорта проекта (MR-008), можно направлять по адресу:
ernat.konirat@gmail.com
Effective date: 6 August 2026 | last updated: 6 August 2026 | version: 2.0
The project’s full official name is MindRelay. The name is formed from two English words: Mind (intellect, consciousness, thought) and Relay (a handover, a delivery, a re-transmission). This compound name accurately reflects the project’s core idea — carrying information and thought from one place to another, from one person to another, like a “relay”, and, in the course of that process, not merely transporting it but processing it, connecting it, and enriching its meaning. The word “Relay” is also used in a technical sense (a device that receives, amplifies and re-transmits a signal) — reflecting that MindRelay performs exactly that function: it receives information, processes it (amplifies/enriches it), and passes it on.
MindRelay is an intelligent information system based on artificial intelligence technologies. This definition can be considered in three parts: “Information system” means that the system’s core function is working with information — receiving, storing, processing and transmitting it; “Intelligent” means that this work is carried out not mechanically but through artificial intelligence, on the basis of understanding meaning; the system is not a single program but a coherent ecosystem of several interconnected components (the bot core, the control panel, the data store, external integrations).
The “face” of the system, and the component that communicates directly with the User, is N.I.R.A. (Neural Intelligent Relay Assistant). The full expansion of the name:
| Letter | In English | Meaning |
|---|---|---|
| N | Neural | based on artificial intelligence/machine learning technology |
| I | Intelligent | responds with understanding, rather than by a simple script |
| R | Relay | echoes the name MindRelay; the function of delivering information |
| A | Assistant | the ultimate role — serving the person |
The relationship between N.I.R.A. and MindRelay can be explained as follows: MindRelay is the name of the whole system (the platform), while N.I.R.A. is the part of that platform visible to, and conversing with, the User. The remaining parts, such as the dashboard, the data store, and external integrations, are not directly visible to the User — they serve indirectly, through N.I.R.A.
MindRelay is currently a project under active development, and at the same time it is genuinely operating in production — that is, it is not merely a prototype or a demo version, but a system used daily, communicating with real Users in real time, and storing real data. These two characteristics (“under active development” and “in production”) are not contradictory — the project is continuously updated and expanded even while it is running (further detail — Section 11, “History of the project”).
The author, the owner of the idea, and the sole developer of the project is Ernat Kalkoz. MindRelay is not a project built by a team or an organisation — the entire architecture, code and content, from the original idea to the present day, has been created by one person (further detail — Section 15, “Author and contact”).
MindRelay uses two core messenger platforms to communicate with Users: WhatsApp and Telegram. The reason for choosing these two — already at the stage of the project’s initial idea (6 June 2026, further detail in Section 11) — was that these two channels were the most widely used, and matched the author’s own need. The word “initial” does not mean that this list is fixed — as shown in Section 13 (“Future plans”), the system may expand to other channels as well.
The ultimate purpose of the MindRelay project, in one sentence, is: to abandon the role of a mere messaging tool and become a platform that gathers information, identifies connections within it, forms knowledge on that basis, and, over time, grows into a coherent intelligent system.
Four stages can be observed in this statement, each arising from the one before: Collection → Connection → Knowledge formation → A coherent intelligent system.
Each stage relies on the outcome of the one preceding it — it is impossible to connect information that has not been collected, impossible to derive knowledge from unconnected information, and a coherent intelligent system is impossible without accumulated knowledge. For this reason, the purpose is considered here as divided into six specific directions — each a link in this chain.
This is the initial, most fundamental link in the chain. MindRelay extracts meaningful data from individual chats, group chats, voice messages and images. Importantly, the collection process is one of selection, not “retaining everything”: the system distinguishes random, insignificant messages from meaningful facts (full technical description — Sections 1–2 of document MR-003; philosophical justification — Section 6 of document MR-006, “Information not included in a profile”).
Information collected does not remain as records isolated from one another — the system searches for a meaningful relationship between them: a connection between a particular person and a project, between a topic and a sub-topic, or a hidden similarity between two different dialogues. For example, the connection between “Ernat” and the “MindRelay” project, or the interrelation between the topics “Robotics” and “Arduino” (full explanation — Section 7 of document MR-006, “Formation of connections”).
On the basis of accumulated and connected information, the system forms generalised conclusions and knowledge elements. This is the stage at which a qualitative leap occurs from the data collected: individual facts (“Ernat uses Arduino”, “X was frequently asked”) turn into general knowledge that possesses independent value, separated from any particular dialogue or User (full explanation — Section 9 of document MR-006, “Formation of knowledge elements”).
The knowledge base is used not only for retention but also to form new ideas, suggestions or approaches to solutions. This is achieved, in particular, by identifying patterns between similar questions and situations — the system can recall similar problems encountered previously and, on that basis, form a new suggestion.
MindRelay retains the prior context of a particular User or topic, which removes the need to re-explain matters when questions recur. This function is especially important from the standpoint of the User experience — instead of starting anew each time, N.I.R.A. “remembers” the User (full technical description — Section 4 of document MR-006, “The concept of profiling”).
The ultimate result of all five purposes referred to in this Section is a timely, contextually appropriate response through N.I.R.A. This purpose is itself the final, visible outcome: for the User, the entire complex internal process (collection, connection, knowledge formation) is externally perceived as a single thing — an accurate and useful answer.
These six directions are not separate, mutually independent tasks — they function as stages of a sequential process. This principle is also confirmed in clause 2.8 of document MR-006: “collection, connection, knowledge formation, idea generation, context retention, and quality improvement are not separate from one another but function as sequential stages of a single process”.
The practical significance of this is as follows: when assessing any new feature or change to MindRelay, one can check whether it aligns with the project’s core purpose by identifying which of these six directions it serves.
Whereas the purpose described in Section 2 shows what the project does, the mission expresses why it does it — what value it serves. A purpose is operational (what needs to be done), while a mission is ideological (why it needs to be done). For MindRelay, the mission is formulated on two levels: a short, memorable version, and an expanded version that reveals it in full.
“Connecting information and turning it into knowledge”
Although this statement consists of only a few words, it captures the entire essence of the project: “information” — the raw material, the initial input (dialogues, messages, facts); “connecting” — the process itself, the transformative action (the “connection” stage in Section 2); “turning it into knowledge” — the final result, the transition of the raw material into a new, higher-level form.
This short version is the “benchmark” formulation used when the project needs to be introduced in a single sentence (for example, when first describing it to a partner).
“MindRelay is a platform that gathers information from a person’s digital life, discovers and structures the connections within it, and, over time, turns it into an intelligent system of knowledge.”
Let us break down this expanded version:
| Part of the statement | Meaning |
|---|---|
| “information from a person’s digital life” | The source is not the User’s real life but their digital traces: messages, dialogues, media |
| “gathers” | Corresponds to the “Collecting information” direction (clause 2.2.1) |
| “discovers and structures the connections” | Corresponds to the “Connecting information” direction (clause 2.2.2) |
| “over time” | Indicates that this is not a one-off action but a continuous, cumulative process |
| “turns it into an intelligent system of knowledge” | The final result is not merely a database but a system capable of thinking and developing |
The phrase “over time” is particularly important here — it signals the mission’s dynamic, rather than static, nature. MindRelay is not a product built once and then left in a fixed state, but a system that changes and develops with every dialogue, with every new User (this idea is explored in more depth later, in Section 12, “Current status”, and in Section 15 of document MR-006, “Continuous development of the knowledge base”).
These two versions do not replace one another — each has its own place: the Short statement — in promotional materials, one-page introductions, spoken descriptions; the Full statement — in official documents (this very Charter), when a deeper explanation is needed for an investor or a partner, or when the project’s core direction is being discussed.
Both statements form the basis of the long-term direction described in Section 4 (“Vision”) — where the mission answers the question “what are we doing now”, the vision answers “what will happen in the future”.
Anyone opening MindRelay today may, on the surface, perceive it as an ordinary personal AI assistant — a bot that communicates through WhatsApp and Telegram, answers questions, and remembers some information. This perception is not wrong, but it is incomplete. Because already at the design stage of the project — that is, even before the first functions were written (6 June 2026, see clause 11.1) — its long-term development trajectory had been built in from the outset.
This is the main reason why the vision section matters: it reveals the ultimate direction lying behind the current, visible everyday functionality. Assessing MindRelay without knowing its vision is like seeing a tree’s current size while disregarding the height to which it is capable of growing.
The system is intended, in the future, to expand to three levels. These levels do not replace one another — rather, each is built on top of the previous one, encompassing it within a broader concept:
The first level is for MindRelay to become not merely an assistant but an operating system managing all of the User’s knowledge. The use of the term “operating system” is deliberate: just as a computer’s operating system coordinates and manages all applications and processes, MindRelay should become the foundation that manages, from a single centre, all of a User’s information flows (across different messengers, topics, projects). At this level, MindRelay will be not just one application, but a platform standing above all other tools.
The second level shifts the terminological emphasis from “operating system” to “memory”. At this level, MindRelay serves as a digital extension of a person’s biological memory: every fact, every connection, every idea that a person forgets, but which was important, is retained in the system and retrieved when needed. The current function described in clause 4.3 of document MR-006 — that “N.I.R.A. ‘remembers’ what the User has said before” — is precisely the earliest, simplest manifestation of this future level. The distinction is that whereas current memory is limited to a single User-N.I.R.A. dialogue, at the “Digital Memory System” level this must be a coherent memory covering a person’s entire digital life.
The third, highest level is the concept of the “second brain”. This term expresses an idea widely used in the field of knowledge management: because a person’s own brain has a limited capacity for memory and processing, this limitation can be overcome by building an external, digital “second brain”. But in the context of MindRelay, this is not merely a passive repository — it is an active, thinking partner: it identifies new connections on its own (Section 8 of document MR-006, “Knowledge graphs”), suggests ideas (clause 2.2.4), and even improves itself (Section 3 of document MR-005, “Purposes of data retention”).
These three levels may be pictured as a staircase: at the bottom — today’s personal AI assistant (the WhatsApp/Telegram bot); above that — the Personal Knowledge Operating System (becoming the foundation that coordinates all information, moving beyond a single assistant); above that — the Digital Memory System (expanding from an individual dialogue to an entire digital life); and at the very top — the “Second Brain” platform (becoming an active, thinking partner).
Each higher level rests on the functional foundation of the one below it, but qualitatively expands it. This explains why the project places the principle of “continuous development” at the forefront (Section 8, “Core principles”): if development stops, the project remains at the first level — an ordinary bot.
Taking this future direction into account, the project’s official definition may be formulated as follows:
“MindRelay is a system that preserves the connections between people, ideas, projects and knowledge, and turns information into long-term intelligent memory.”
It is useful to compare this definition with the full statement of mission in Section 3: the mission places emphasis on the process (“gathers... turns it into”), while the vision emphasises the outcome (“preserves... memory”); the mission reflects a present action, while the vision reflects a long-term goal; in the mission the key word is “Platform”, while in the vision it is “System”.
The distinction between them is not fundamental — the mission answers “what are we doing now”, and the vision answers “what will it ultimately become”. Both are two temporal projections of a single direction.
The significance of this Section is not merely declarative — it is practical: the concrete directions for development set out in Section 13 (“Future plans”) — a mobile version, expansion of the web panel, growth of the knowledge graph — are all steps corresponding to particular points along this three-level trajectory. In other words, the vision is not a list of abstract dreams but a compass guiding the project’s concrete development plan.
One of the first questions that had to be resolved when designing MindRelay was whether to write the system as a single, monolithic program, or to divide it into several separate parts. The choice fell on the latter: MindRelay follows an approach close to a microservices architecture, though it is not a pure microservices architecture — it is an intermediate solution. In a fully microservices-based system, each component can be entirely independent, potentially even hosted on a separate server. In MindRelay, components are connected to one another through HTTP/API and a shared file system, but for the most part they run on a single machine, in close coordination.
The reason for choosing this intermediate approach is practical: for a sole developer (clause 1.5), managing a full microservices architecture would be an excessive organisational burden, while writing everything into a single monolithic file would have led to code that is very difficult to read and risky to modify (concrete evidence — the main.py file itself exceeded 8,500 lines, further detail in clause 11.5). An intermediate path was therefore chosen: division by functional responsibility, but not by physical location.
This choice has three specific advantages: Independent development — a change in the bot core does not break the dashboard, and vice versa; Isolation of failures — if a fault occurs in the WhatsApp bridge, communication continues through Telegram (the bot core manages both independently); Technological freedom — each component can use the technology best suited to it (see clause 5.4 — why the WhatsApp bridge is written in Node.js rather than Python).
This is the central, coordinating component of the system. Written in Python, based on the Flask web framework, running on port 5000. Its responsibilities include: receiving all messages arriving from WhatsApp and Telegram; analysing a message, determining its language, and tagging its category (whether it is a question, a request, or a complaint); fully managing dialogue logic — greeting scenarios, the main conversation, and farewell scenarios are all handled here; invoking the modules in the core/ package (see clause 5.2.2) and coordinating them with one another; establishing direct communication with AI providers (OpenAI, Groq, Google) (further detail — Section 7); and writing all results to the data store via obsidian/writer.py.
The current size of this file is approximately 8,500 lines (441 KB), making it the largest and most important single file in the project. This size itself raises a concern — a note on which is given in clause 5.6.
If the bot core (main.py) is the system’s “heart” — the central component sustaining circulation — then the core/ package is its “brain”, the place where the actual intelligent and computational logic is concentrated. This package consists of several independent modules:
| Module | Class/function | Responsibility |
|---|---|---|
| agent.py | MindRelayAgent | The core agent logic — N.I.R.A.’s “decision-making” centre |
| pipeline.py | CognitivePipeline | The cognitive-processing chain — the sequence of steps from receiving a message to producing a response |
| knowledge_graph.py | — | The structure and logic of the knowledge graph (full explanation — Section 8 of document MR-006) |
| learning.py | LearningSystem | The system’s self-learning mechanism (the daily learning log, clause 3.2 of document MR-005) |
| rag.py | ObsidianRAG | Retrieval-Augmented Generation — the system for finding relevant information within the knowledge base |
| calendar_service.py | GoogleCalendarService | The service layer for Google Calendar integration |
| category.py | — | The logic for dividing Users into categories (Section 5 of document MR-006) |
| scheduler.py | SchedulerService | Triggers scheduled tasks (for example, nightly self-testing) when their time arrives |
| weekly_report.py | — | Compiling weekly summary reports |
This modular division is significant: to understand the difference between agent.py and pipeline.py — the agent is the logic that decides “what needs to be done”, while the pipeline represents the order in which that decision is carried out through concrete steps (receiving the message → detecting the language → loading context → sending to the AI → processing the response → saving).
This package consists of two files: telegram_bot.py and whatsapp_bot.py. Their task is to isolate the peculiarities specific to each communication channel (message format, identification method, API limitations) from the bot core. Thanks to this separation, channel-specific difficulties such as the WhatsApp LID/number issue (see clause 11.5) can, for example, be resolved solely within this one file, without affecting the rest of the system.
The ObsidianWriter class in writer.py is the system’s single point of connection with the data store (Obsidian). This is an important architectural decision: the remaining parts of the system do not write files directly — instead, all write operations pass through this one central point. The advantage of this is ensuring consistency of the file structure and naming rules (aligned with the sections of document MR-006 concerning file structure): should the file structure need to change in the future, it is sufficient to amend only this one file.
A Flask application entirely separate from the bot core, running on port 8080. The reason for this separation is important: if the control panel ran in the same process as the bot core, a heavy operation in the dashboard (for example, generating a large report) would slow down the bot’s responses. Running as a separate process eliminates this risk. The current size of this file is approximately 4,600 lines. Its full functional description is given in Section 6 (“Technology stack”) and in the Terms of Use (MR-002).
The only component written in Node.js (the reason is given in clause 5.4). It uses the @whiskeysockets/baileys library, which establishes a direct, unofficial connection (not via the WhatsApp Business API) with the WhatsApp Web protocol. Authorisation is carried out via a QR code — the User (in this case, the author personally) scans the QR code with the WhatsApp application on their phone, after which the session is saved, so re-scanning is not required the next time (session data is stored in the auth_info/ folder).
This package, consisting of more than 20 JSON files, stores the system’s “not long-term, but significant” state — for example, the list of VIP contacts, the state of open requests (zapros), gamification data (quests, statistics), the history of ratings trends, the state of rule suggestions, the latest result of nightly self-testing. These files differ from the Obsidian data store — whereas Obsidian retains “substantive” information (dialogues, profiles, knowledge), config/ retains the system’s “operational” state.
This package is a component intended not for the system’s internal operation but for its outward-facing relationship: index.html, about.html, documents.html, and files corresponding to precisely this series of documents — doc-privacy.html, doc-terms.html, doc-retention.html, doc-liability.html, doc-ai-policy.html. This is concrete evidence that MindRelay strives to be not merely a technical system, but a project that is open and accountable to its Users (further detail — Section 8, “Core principles”, the “Transparency” principle).
Let us trace the complete path of a single message step by step — from the moment a User sends a message via WhatsApp until a response is received:
Reception: the message reaches the whatsapp/index.js bridge from WhatsApp’s servers (via the Baileys library);
Forwarding: the bridge sends the message as an HTTP request to the bot core (main.py, port 5000);
Pre-processing: the bot core processes WhatsApp-specific formatting via bots/whatsapp_bot.py (for example, the LID/number issue is resolved here);
Cognitive processing: the message is passed to the CognitivePipeline in core/pipeline.py, which detects the language, loads context from Obsidian via core/rag.py, and tags the category via core/category.py;
Decision-making: the MindRelayAgent in core/agent.py decides what to do — respond directly, or formalise the matter as a request (zapros);
Calling the AI: depending on the action selected, the request is sent to the chain of AI providers (Section 7);
Writing: the result — a new fact, an updated profile, a dialogue record — is written to the data store via obsidian/writer.py;
Returning the response: the response formed is sent back from the bot core to the whatsapp/index.js bridge, and then, through WhatsApp’s servers, reaches the User.
As a parallel branch of this chain, the control panel (dashboard/app.py) can, at any moment, read the outcome of this process directly — the updated Obsidian files and config/ state files — since, as a separate process, it has access to the same shared file system.
A reader may reasonably ask: why is the entire system not written in a single language? The answer lies in the principle of choosing the right tool for each task. The most stable, widely used library for establishing a direct, unofficial connection with WhatsApp — Baileys — is built for the JavaScript/Node.js environment. Rather than “rewriting” it in Python, the choice was to use the ready-made, proven solution in its own environment, connecting it to the rest of the Python system only via HTTP. This is a concrete example of the “technological freedom” advantage referred to in clause 5.1.
Both the bot core and the control panel use one shared data store — a Markdown-based file system built on Obsidian — in place of a traditional relational database (MySQL/PostgreSQL). The full rationale and advantages of this choice are given in detail in clause 6.3 (Technology stack) and in documents MR-003 and MR-006.
In keeping with the principle of transparency (Section 8), it is appropriate here to also note the system’s current architectural shortcoming: the size of the bot core (main.py) has, over time, grown to 8,500 lines, which is a very large size for a single file. In traditional software engineering practice, logic of this size is usually divided into several smaller modules. This is a natural consequence of the project’s rapid, iterative development (Section 11), and is also considered one of the directions for future improvement (Section 13).
MindRelay’s three core computational components — the bot core, the control panel, and all modules of the core/ package — are written in Python. There are several concrete reasons for this choice: compatibility with the artificial intelligence ecosystem — all AI providers such as OpenAI, Groq and Google Gemini have official Python client libraries; convenience for working with text — Python’s text-processing and file-handling capabilities are naturally suited to working with an Obsidian-based data store; the ability to develop quickly — for a sole developer, Python’s simple syntax and extensive library ecosystem increase development speed.
The version currently used in the project is Python 3.13.3, one of the latest stable releases of the language.
Flask is the web framework underlying the system’s two main HTTP servers (the bot core and the control panel). The reason for choosing Flask over “batteries-included” frameworks such as Django is its lightweight, minimalist nature: MindRelay does not need the complex features offered by Django, such as a full ORM, an admin panel, or an authentication system, since the data store is not a relational system but the Obsidian file store (clause 6.3).
The only core backend technology outside Python. The reason for its use is fully explained in clause 5.4 — the fact that the Baileys library is native to the JavaScript environment. The Node.js version used is v24.16.0.
Flask’s own built-in development server is intended for testing only and is not suited to handling many simultaneous requests or to stable, ongoing operation. MindRelay therefore uses the waitress library as its WSGI server in production (clause 1.4) — running the Flask application reliably, in a multi-threaded manner.
The control panel’s interface is built on HTML5, CSS3 and plain (Vanilla) JavaScript — no separate frontend framework such as React, Vue or Angular is used. This decision has a considered rationale: lightness and speed — an interface without a framework loads faster in the browser; no build step — React/Vue typically require a build process such as npm run build; Vanilla JS allows immediate results to be seen without this additional step, by directly editing the file and refreshing the browser; simplicity for a sole developer — using directly familiar, standard web technologies instead of mastering the learning curve and ecosystem of a large framework.
This choice also has a downside — in large interfaces, Vanilla JS code can become unstructured, an issue that echoes the general architectural limitations referred to in clause 5.6.
All the statistical charts and graphs in the control panel (the monitoring page, daily/weekly trends) are drawn using the Chart.js library. This is a lightweight, widely used library built on HTML5 Canvas, supporting core chart types such as donut, bar and line.
Instead of a traditional relational database (MySQL, PostgreSQL, SQLite), MindRelay uses a system called Obsidian, originally built for personal knowledge management and based on Markdown files. This is one of the project’s most distinctive architectural decisions, and its rationale merits closer examination.
| Advantage | Explanation |
|---|---|
| A human-readable format | Data is stored as ordinary text (.md) files — they can be read directly with any text editor, without a dedicated database client |
| A natural linking system | Obsidian’s own [[wiki-link]] syntax allows links to be established between files — this naturally aligns with the knowledge-graph concept (Section 8 of document MR-006) |
| Independence from a server | The data store does not require a dedicated server process — data resides directly in the file system, which simplifies backup to the level of a simple file copy |
| A flexible structure | There is no rigid tabular (table/schema) constraint — each User folder (clause 4.2 of document MR-003) may have a freely organised internal structure |
This choice also has consequences — the complex queries (JOINs, aggregation) typical of relational databases are impossible, or more difficult to implement, and search speed over large volumes of data may be lower than with a specially indexed database. It is precisely for this reason that a dedicated ObsidianRAG system was built in the core/rag.py module — it serves as an additional layer for efficiently locating information within Obsidian files.
The full technical description, file structure and retention arrangements are set out in documents MR-003 (Data Collection, Processing and Knowledge Formation Policy) and MR-006 (Knowledge Base and Profiling Policy).
In addition to the core stack described above, MindRelay uses several specialised external services and libraries, each responsible for a specific function:
| Service/library | Purpose | Context of use |
|---|---|---|
| Google Calendar API | Checking the owner’s schedule | In “Scheduled” operating mode, N.I.R.A. automatically determines the Operator’s availability from the calendar (clause 4.5 of document MR-002) |
| OpenAI Whisper | Converting voice messages into text | Whenever a User sends a voice message, transcription is carried out through this service |
| OpenCV (cv2) | Extracting frames from video files | When a video message arrives, the system automatically extracts the first frame and analyses it via AI Vision |
| pypdf | Analysing PDF documents | If a User sends a PDF file, its textual content is extracted through this library |
| python-docx | Processing Word documents | For reading and processing documents in Word format |
| Twilio | SMS / an additional communication channel | Tested/connected as an additional or alternative communication channel |
Each of these integrations forms the technical foundation of the system’s “media-processing” layer (clause 3.6 of document MR-002, “Supported content types”) — ensuring that a User is not limited to text and can send voice, images, video, and documents.
MindRelay’s ability to respond depends fundamentally on external artificial intelligence services — if an AI provider is unavailable, N.I.R.A. cannot respond. If the system depended on only one provider (for example, OpenAI alone), any temporary failure of that provider (a server outage, an exhausted quota, scheduled maintenance) would result in the complete failure of the entire MindRelay system.
To avoid this risk of a single point of failure, the system uses a multi-tier (fallback chain) structure of AI providers rather than a single one. The logic of this approach is straightforward: if the first-tier provider is unavailable, the system automatically switches to the second tier; if that too is unavailable, it moves to the third. For the User, this switch is entirely invisible.
| Tier | Provider | Role and reason for selection |
|---|---|---|
| 1 (primary) | OpenAI (GPT-4o-mini) | Distinguished by its ability to give the highest-quality, most accurate and contextually appropriate responses. This model is used in day-to-day, core operation. |
| 2 (backup) | Groq (Llama 3.3 70B) | Activated when OpenAI is unavailable or a limit is exceeded. Distinctive feature — thanks to Groq’s dedicated computing infrastructure (LPU), response speed is considerably higher. |
| 3 (final backup) | Google Gemini (2.0 Flash-Lite) | The last safety net should both preceding tiers be unavailable. |
This three-tier chain ensures the system does not depend on a single external service and guarantees that the bot can continue operating even if any one service is temporarily unavailable.
The history of the image-analysis function is a vivid example of the project’s genuine experience of technical decision-making. This function was originally implemented through Google Gemini Vision. However, Gemini’s free-tier request quota was exhausted fairly quickly — practical proof that the free quota was limited under real production load. Following this, the architecture was switched entirely to OpenAI Vision, and this switch has been retained to this day.
This event is also recorded among the development stages described in Section 11 (“History of the project”) (clause 11.5) — proof that the project develops not only according to plan, but also by adapting to genuinely encountered technical constraints.
The security measures applied when sending data to AI providers (the confidentiality of API keys, an encrypted communication channel, the exclusion of confidential information from system logs) are not described in full in this Charter, but specifically in Section 8 of document MR-007 (Security Policy) (“Security of third-party services”). How, and for what purpose, User data is transmitted to AI providers is set out in Section 6 of the Privacy Policy (MR-001).
The three-tier chain described in clauses 7.1–7.3 reflects the current situation, but it is not fixed. Given the rapid pace of development in the field of AI technologies, the composition and order of the provider chain may change in the future (for example, when a new, more efficient model is released, or when the price/quality ratio of existing providers changes). This is a further manifestation of the system’s principle of “continuous development” referred to in Section 8.
To understand this Section correctly, it is first necessary to establish one important boundary: the principles described here are the project’s principles at the product level — that is, they answer the question of what character MindRelay should have overall, and what direction it follows. These principles should not be confused with the philosophy relating to data retention (addressed separately in clauses 17.2 and 17.5 of document MR-005) — the latter covers the narrower matter of the ownership and eventual fate of specific User data, whereas the list here defines the project’s coherent, overall direction and behaviour.
Let us clarify this distinction with a concrete example: the “Transparency” principle (clause 8.2) means that the project’s architecture and development history are not concealed (the product level), whereas the “principle of transparency” in document MR-005 (clause 16.5) means that a User may, at any time, ask about the content of their own profile (the data level). Although both are called “transparency”, each answers a different question.
The purpose, architecture and development history of the MindRelay project are not concealed. A concrete manifestation of this principle is this very document (the Project Charter): the project openly describes its internal structure (Section 5), its actual growth history (Section 11), and even its architectural shortcomings (clause 5.6). Furthermore, the existence of the trust_center/ component (clause 5.2.8) is evidence of transparency implemented at the technical level.
Protection of User data is taken into account at every level of the project — from architectural isolation (the centralised writing mechanism in clause 5.2.4) to the structure of system logs (clause 7.4). The full, technical-level implementation of this principle is set out in document MR-007 (Security Policy).
Personal data is used only for purposes clearly agreed with the User — it is not used for advertising, commercial sale, or disclosure to third parties. The full legal basis for this principle is set out in document MR-001 (Privacy Policy).
This principle is, perhaps, MindRelay’s most defining characteristic. The project does not stand still — as shown in Section 11 (“History of the project”), new functionality was added almost every week, and this process continues to this day (Section 12, “Current status”). This principle is directly linked to the three-level development trajectory described in Section 4 (“Vision”) — if development were to stop, the project would remain at the level of a “Personal AI assistant”, never reaching the level of a “Personal Knowledge Operating System”.
The priority is given not to the mere retention of information, but to extracting meaning and connections from it. This principle is the deepest of the six directions described in Section 2 (“Purpose of the project”) — the philosophical basis for prioritising the synthesis of new knowledge from data over the mere collection of data. At the practical level, this principle is fully explained, technically and legally, in Sections 9 and 10 of document MR-006 (“Formation of knowledge elements” and “Ownership of the knowledge base”).
Building a coherent, interconnected context, rather than isolated facts, is the core feature that distinguishes MindRelay from an ordinary chatbot (Section 10, “What sets the project apart”). This principle is concretely, technically implemented in the concept of the knowledge graph (Section 8 of document MR-006): individual connections intersect with one another over time, turning into multi-level, richly meaningful structures.
These six principles are not an isolated list — they are closely interconnected. For example, the intersection of the principles “Continuous development” (8.5) and “Transparency” (8.2) means that every change in the project is not hidden, but that development itself is publicly documented (through this Charter). Likewise, “Knowledge formation” (8.6) and “Connecting information” (8.7) are two neighbouring stages of the sequential process described in Section 2 (collection → connection → knowledge formation), so these two principles have no full meaning without one another.
This interrelation is not accidental — all six principles, ultimately, express different facets of the single core idea formulated in Section 3 (“Mission”) — “connecting information and turning it into knowledge”.
In describing MindRelay’s target audience, a single list is insufficient, because, as shown in Section 4 (“Vision”), the project must be considered not only in its current state but also along its long-term development trajectory. The audience is therefore also described in two distinct temporal layers: the current, actually existing audience, and the future, not-yet-realised audience anticipated further ahead. These two layers differ fundamentally from one another — the first corresponds to the project’s current technical and organisational capabilities, while the second is directly connected to the development levels set out in Section 4.
It is important to highlight this category specifically, because MindRelay originally arose (clause 11.2, “History of the project”) from precisely this person’s personal need: overcoming dyslexia, unifying all messengers, and managing information and the daily schedule. The author is, therefore, not merely a tester or an administrator, but a real User who was the system’s original, first design target. This is a respect in which MindRelay differs from many projects: its features were originally built in response not to an abstract “average user” but to a concrete, measurable personal need.
Besides the author, the individuals who communicate with MindRelay are Users who contact N.I.R.A. via WhatsApp or Telegram, ask their own questions, and leave requests (zapros) (full legal definition — Section 2 of document MR-002, “Terms and definitions”). This category includes, in particular, clients, partners and acquaintances who correspond with the author.
N.I.R.A. can take part not only in individual dialogues but also in group chats (full technical description — clause 3.4 of document MR-002 and Section 2 of document MR-003). In this case, the audience is not an individual but a small group or community — the nature of interaction here differs from an individual chat (for example, N.I.R.A. does not, by default, give a public response in a group; it only listens).
These categories are directly linked to the development levels described in Section 4 — each successive type of audience requires the system to have reached the corresponding level.
MindRelay reaching the “Personal Knowledge Operating System” level (clause 4.2.1) is a precondition for turning it into a system able to serve not one person but an entire organisation. This expansion is already anticipated in clause 1.10 of the MindRelay Terms of Use (MR-002): “The Platform may in the future be made available to third parties for use in their own name and for their own purposes”, where the concept of “holder” corresponds precisely to this organisational audience.
The natural field of application for the “Digital Memory System” level (clause 4.2.2) is education. Connecting learning materials, course structures, and students’ questions and answers, and structuring them as a knowledge graph (Section 8 of document MR-006), could be of particular value for educational projects.
The “Second Brain” platform level (clause 4.2.3) corresponds directly to the nature of research work: researchers frequently seek connections among large volumes of information, sources and ideas — precisely MindRelay’s core purpose (Section 2). For research groups, the system could become a tool for building a shared knowledge base.
The expansion of the audience from an individual User to organisations is a direct consequence of the “Continuous development” principle described in Section 8. But this expansion must be balanced against the “Confidentiality” principle in clause 8.4 — specifically, clause 1.10 of document MR-002 expressly states that each “holder” is an independent operator in respect of its own Users, and is solely responsible for processing personal data. The expansion of the audience therefore requires a corresponding division of responsibility — a matter that will be regulated in greater detail in the relevant legal documents as new categories are actually realised.
Someone seeing MindRelay for the first time from the outside may readily take it for “yet another WhatsApp bot” — the market today has dozens, even hundreds, of superficially similar chatbots. It is therefore necessary to show, with precise, concrete evidence, exactly what distinguishes the project — not vague claims of “we are different”, but a concrete distinction at the technical and architectural level.
The clearest way to demonstrate the distinction is to set out what MindRelay is NOT, alongside what it IS:
| MindRelay is NOT | MindRelay IS |
|---|---|
| ❌ An ordinary chatbot | ✅ A knowledge-formation system |
| ❌ An ordinary information store | ✅ A connection-discovery system |
| ✅ An intelligent assistant |
The structure of this table is deliberate: the left column lists two categories that superficially resemble MindRelay but are fundamentally different (“chatbot” and “information store”), while the right column gives three concrete characteristics showing exactly how MindRelay differs from each of these two categories.
An ordinary chatbot operates on a fixed scenario: a question arrives → a pre-written response is given, or a response follows limited logic → the dialogue ends, effectively leaving no trace. MindRelay differs from this in three concrete ways: context is retained (Section 4 of document MR-006) — although a dialogue ends, the facts and connections derived from it are not lost; the response is not static — N.I.R.A. can give different, context-adapted answers to the same question at different times (clause 8.2.4 of document MR-002); it develops beyond the dialogue — the system’s self-learning mechanism (Section 3 of document MR-005) also operates outside a dialogue, even at night.
An ordinary information store (for example, an ordinary database or document repository) retains data but does not independently search for connections among it — searching is carried out passively, only on a specific request. MindRelay differs from this through its active, independent ability to identify connections: automatic connection identification (clause 7.8 of document MR-006) — “connections are identified automatically, using artificial intelligence... no separate confirmation from the User is required”; a multi-level structure (Section 8 of document MR-006, “Knowledge graphs”) — individual connections intersect with one another over time, turning into multi-layered chains such as “Ernat → MindRelay → N.I.R.A. → Arduino → Robotics → the ‘Phaeton’ project”; a change in the nature of ownership (Section 10 of document MR-006) — processed information is separated from its original source, acquiring new, independent value — a property entirely absent from an ordinary information store.
All the evidence cited above rests on three specific sections, which we point out specifically to a reader wishing to explore them in more depth: Section 5 (in this document, “System architecture”) — the diversity of components: a mere messaging tool would not need the nine modules of the core/ package, a knowledge graph, or a RAG system; Section 7 (in this document, “The multi-tier structure of AI providers”) — for an ordinary scripted bot, a three-tier fallback chain would be excessive; this is a sign of investment in a deep, stable intelligent capability; Sections 8 and 10 of document MR-006 (“Knowledge graphs” and “Ownership of the knowledge base”) — these two sections form the project’s deepest, most conceptual layer.
The three distinguishing features described in this Section (“not an ordinary chatbot”, “not an ordinary information store”, “an intelligent assistant”) are not accidental — they are the direct technical expression of the mission formulated in Section 3 (“connecting information and turning it into knowledge”). Had the project been merely a chatbot, or merely an information store, the mission would not have been fulfilled: a chatbot does not connect, and an information store does not turn information into knowledge. It is precisely this simultaneous transcendence of both limitations that forms the structural basis of MindRelay’s distinctiveness.
Every date, event and direct quotation given in this Section is neither invented nor generalised in nature — it is based on a genuinely verified source: the actual conversation history from the project’s early stages, and the output of a read-only inventory script run locally by the author (the actual modification dates and sizes of files). This methodological rigour matters, because the “history” of many projects is later recalled and written in an idealised form — whereas the chronology set out here is directly confirmed by archival data.
The project began on 6 June 2026, with the author’s simple suggestion: “Let’s start a new project.” When asked what specifically to build, the answer was: “I want to build an AI agent.” This was a starting point at the level of a general idea only — the project’s name, architecture, and even its concrete functions had not yet been determined.
In the course of subsequent clarification, the author’s request was broken down into three specific, distinct tasks:
| No. | Task | Underlying reason |
|---|---|---|
| 1 | Overcoming dyslexia | The author’s own need to automatically correct their writing errors across three languages (Kazakh, Russian, English) — the project’s most personal, most human impetus |
| 2 | Unifying communication channels | Managing messages from all messengers in one place, responding on the author’s behalf |
| 3 | Collecting information and managing the daily schedule | Processing requests received from people and bringing them to the author’s attention |
The combination of these three tasks is significant: MindRelay did not originally arise as a tool for solving a single problem, but as an idea for uniting three distinct personal needs within one system. It was precisely this principle of “unification” that later grew into the project’s core mission (“connecting information and turning it into knowledge”, Section 3).
Several well-founded technical choices were made within that very same session: Platforms — WhatsApp and Telegram (both selected, not just one); Data store — Obsidian, in local mode — cloud alternatives were not considered; The initial development plan — divided into four stages: Stage 1 — a Telegram bot + dyslexia correction; Stage 2 — WhatsApp integration; Stage 3 — automatic Obsidian writing; Stage 4 — daily-schedule management.
It is interesting to compare this original four-stage plan with the actual development history in clause 11.5: whereas the plan was linear (sequential), actual development proceeded in many directions and considerably faster — a phenomenon typical of any software project.
The project’s second day is a striking indicator of its pace of development. In a single day, nearly all of the following were built more or less simultaneously: the first version of the control panel (the dashboard); Google Calendar integration; the initial version of the knowledge graph (the knowledge_graph.py file); and the chats page.
This “explosive” growth is not coincidental — it shows that the author’s original idea was sufficiently concrete and fully thought through, so that the process of turning it into code was not significantly slowed. Nonetheless, such rapid initial construction also created areas that required structural revision at later stages (clause 11.5) (for example, “the full restructuring of chat history”).
Choosing the Assistant’s name is one of the project’s most memorable moments, marking the point when its “soul” emerged. This process went through several concrete stages:
Kazakh options: “Zharqyn” (in the sense of “bright, intelligent”), “Senim” — but these did not match the author’s preference;
The international “ARIA” direction: the full expansion Artificial Relay Intelligence Assistant was proposed;
A request for clarification: the author specified “something in the same spirit as ARIA, but different” — signalling the need to search for new meaning while preserving the same sound pattern;
Options in the A-R-I-A format: MIRA (Mind Intelligent Relay Assistant), VERA (Virtual Ernat Relay Assistant), KIRA (Knowledge Intelligent Relay Assistant), and NIRA (Neural Intelligent Relay Assistant) were proposed;
The final choice: the author made the decision — “let the name be NIRA”.
The name NIRA was subsequently fixed in official documents in the form N.I.R.A. (with full stops) (see clause 1.3). The Relay portion of this name echoes the name MindRelay, and this is deliberate: although the name was devised as if for an individual persona, it was important that it remain connected to the system’s larger brand — MindRelay.
Once the name had been chosen, the Assistant’s character was also defined immediately, within that same session: using emojis; speaking in a friendly tone; giving short answers, but openly stating when it cannot provide fuller information should the User wish for it; warm and caring; continuing in whichever language the dialogue began, and, where the language is difficult to determine, asking the User to clarify which language they wish to converse in; and, when it does not understand, not inventing anything on its own but asking a clarifying question.
The final point of this character description — the requirement to “invent nothing” — later corresponds directly to the principle legally established in clause 8.7 of the MindRelay Terms of Use (MR-002) (“Errors and limitations of accuracy”).
This period represents the project’s most intensive phase of development, confirmed not only qualitatively but by concrete numerical evidence. Data obtained by measuring the size of the bot core (main.py):
| Date | Size of main.py | Growth from previous measurement |
|---|---|---|
| 23 June 2026 | 2,692 lines | — (baseline measurement) |
| 27 June 2026 | 2,796 lines | +104 lines (over 4 days) |
| 29 June 2026 | 3,416 lines | +620 lines (over 2 days) |
| 7 July 2026 | 4,315 lines | +899 lines (over 8 days) |
| 9 July 2026 | 5,140 lines | +825 lines (over 2 days) |
| 14 July 2026 | 6,282 lines | +1,142 lines (over 5 days) |
The pattern visible in this table is that the growth rate is not constant but wave-like: some two- or three-day periods added hundreds of lines (for example, 27→29 June), while at other times growth slowed. This is a phenomenon typical of an individual developer’s working rhythm, and each large leap generally coincides with the addition of a single major feature.
Improving dialogue context and the memory system. In the original version, N.I.R.A. responded to each message separately, “forgetting” the preceding part of the dialogue — a shortcoming directly contrary to MindRelay’s core purpose (“retaining context”, clause 2.2.5). As a fix, a system was built in which the last 5 messages are retained in full, with earlier ones held as an AI-condensed summary.
The “hidden mission” — the information-gathering system. In line with the author’s specific requirement that “the bot should not only answer, but also gather information about people, continuing to develop the knowledge base”, a mechanism was built that automatically extracts facts from a dialogue and writes them, structured, into the Obsidian structure (Contacts/Category/Name). This means that the core technical foundation of today’s document MR-003 was laid during this period.
Adding media support. The bot was expanded so that it could accept not only text but also voice messages, images, video, and documents. It was precisely during this period that the switch from Google Gemini Vision to OpenAI Vision, described in clause 7.3, took place.
Building the Dashboard’s core pages. Core pages such as Monitoring, Bot Report, and Bot Management were designed and programmed — the functional foundation of the control panel described in clause 5.2.5 was laid at this time.
Resolving the WhatsApp LID/number issue. During testing of the message-sending functionality, the discrepancy between WhatsApp’s internal identifier (LID) and the actual phone number caused numerous errors — messages failed to reach some contacts. This was resolved by adding logic that automatically detects the number format and selects the appropriate one.
Full restructuring of chat history. The original version read only from /api/inbox and could not correctly display contact names — likely a consequence of the “explosive” rapid construction described in clause 11.3, since quickly built first versions often require a full revisit later.
On this day, separately from technical development, the project began systematically producing legal-trust documentation. In sequence, the following were published: the Privacy Policy (MR-001) → the Terms of Use (MR-002) → the Data Collection, Processing and Knowledge Formation Policy (MR-003) → the Data Retention and Deletion Policy (MR-005) → the Knowledge Base and Profiling Policy (MR-006) → the Security Policy (MR-007) → the Project Charter (MR-008) — this document.
This period is of considerable significance: it marks the project’s transition from the status of merely “working code” to that of an “accountable, open project” (a concrete implementation of the “Transparency” principle from clause 8.2). The number MR-004 (likely to be “Limitation of Liability”) was deliberately left vacant — it is currently considered to be covered by Section 10 of the ToS, and has been deferred as a separate document to a later date.
The bot core reached 8,583 lines (441 KB). Compared with the starting point in clause 11.2 (zero on 6 June), this represents growth of more than a hundredfold over roughly two months. Nonetheless, this numerical growth has also produced the architectural limitation referred to in clause 5.6 — a single file reaching such a size is recognised as a matter requiring structural improvement.
Between 2 June and 2 July 2026, at precisely the same time as MindRelay, the author built an additional, physical project called Faethon — a gesture-controlled sensor-based intelligent lamp based on Arduino and RGB LEDs. The name itself is taken from ancient Greek mythology, from Phaethon (“the shining one, the radiant one”).
This project is marked as “Completed”, but its significance for MindRelay has not diminished — on the contrary, its name has become the most vivid example of MindRelay’s knowledge-graph concept: “Ernat → MindRelay → N.I.R.A. → Arduino → Robotics → the ‘Phaeton’ project” (clause 8.2.2 of document MR-006).
This is not merely an invented illustration but a genuine reflection of the author’s real, parallel second project, and a self-demonstrating example of MindRelay’s ability to “identify connections” (clause 10.4): the system draws its own examples from the author’s real life.
| Date | Event |
|---|---|
| 6 June | The project began (three motivations identified) |
| 7 June | Explosive first day (dashboard, calendar, graph) |
| 2 June – 2 July | The Faethon project (parallel, independent) |
| 11 June | The farewell system was added |
| 14 June | Naming: N.I.R.A. + character defined |
| 23 June | main.py: 2,692 lines |
| 29 June | main.py: 3,416 lines |
| 7 July | main.py: 4,315 lines |
| 9 July | main.py: 5,140 lines |
| 14 July | main.py: 6,282 lines |
| 1 August | The Trust Center began (starting with MR-001) |
| 1–2 August | main.py: 8,583 lines (current size) |
| 6 August | MR-006, MR-007 and MR-008 completed (today) |
MindRelay is currently (as of 6 August 2026) a fully operational system, running in production (in line with the status referred to in clause 1.4). This is not a project of a theoretical or demonstrative nature: the bot converses in real time with clients over WhatsApp and Telegram, processes the information it receives from them, and the author is able to directly monitor this entire process through the control panel and intervene where necessary.
To unpack the concrete content of the term “fully operational”, it is worth considering the current state of each part of the system separately.
All of the control panel’s core pages (dashboard/app.py), described in Section 5 (“System architecture”), have fully passed testing and operate stably:
| Page | Function |
|---|---|
| Dashboard | Displaying overall statistics and the system’s current status at a glance |
| Monitoring | Detailed tracking of dialogues, ratings, and activity |
| Bot Report | A summary report on the quality of the bot’s performance |
| Bot Management | Directly managing the bot — changing modes, sending messages, configuring parameters |
| Chat History | Viewing and searching the history of all dialogues |
| Obsidian base | Browsing the data store directly through the web interface |
The statement that each of these pages “has passed testing” is not incidental — as described in clause 11.5, some pages (for example, Chat History) did not function fully in their original version and later required a full restructuring. Accordingly, the “current stability” is the result not only of adding new features but also of fixing identified shortcomings.
Beyond its core, functional purpose, MindRelay has also been given an additional gamification layer. This layer includes: RPG-style statistics — displaying certain metrics of the system or the User in the form of role-playing-game-style statistics; a quest/skills system — a mechanism of tasks and skill development aimed at achieving certain goals; an XP/level system — a progress indicator based on experience points and levels; achievements — titles or badges awarded upon reaching certain milestones.
The presence of this layer reflects MindRelay’s effort to make the User experience (including the author’s own experience) not merely a “dry” functional tool but an engaging and motivating one. Gamification elements do not directly conflict with any of the principles referred to in Section 8 — on the contrary, they serve as a day-to-day motivational instrument for the principle of “Continuous development” (clause 8.5).
One important characteristic that sets MindRelay apart from other ordinary chatbots (Section 10) is that it has mechanisms that develop on their own, beyond the dialogue. These mechanisms are currently active: nightly self-testing — the system re-examines its previous responses at a set time period (at night) and assesses their quality; the rule-suggestion system — the system draws conclusions from its own experience and proposes new behavioural rules (these proposals do not take effect automatically; they require the Operator’s approval); self-expansion of topics — independently recognising new, previously undefined topics and adding them to the knowledge graph; monitoring the ratings trend — observing how ratings received from Users change over time, identifying a trend; automatic FAQ generation — identifying frequently asked questions and building a base of ready-made answers to them.
This list is described in greater technical and legal detail in documents MR-003 (Data Collection, Processing and Knowledge Formation Policy) and MR-006 (Knowledge Base and Profiling Policy) — in particular, how these mechanisms operate while preserving the confidentiality of User data (for example, the anonymisation of knowledge elements, clause 9.8.2 of document MR-006) is fully explained in those documents.
The three levels described in this Section — core functionality (12.2), the additional experience layer (12.3), and self-development mechanisms (12.4) — together indicate exactly where MindRelay currently stands on the path from the “Personal AI assistant” level to the “Personal Knowledge Operating System” level described in Section 4: the core functionality is fully stabilised, while the system’s independent development and its ability to identify connections (the knowledge graph, self-improvement) are active but still maturing.
This Section answers two interrelated but distinct questions: for what purpose are we building this project (expected results — relating to the ideal, ultimate goal), and what specifically are we doing (directions for development — the concrete, planned steps in the near future). The first echoes directly the six directions from Section 2 (“Purpose of the project”); the second grows out of the concrete technical foundation described in Section 12 (“Current status”).
This list represents the ultimate criteria against which the success of the MindRelay project is measured. Each is directly linked to a specific purpose in Section 2:
| Expected result | Corresponding purpose in Section 2 |
|---|---|
| Structuring of information | “Collecting information” (clause 2.2.1) |
| Retention of context | “Retaining context” (clause 2.2.5) |
| Formation of knowledge | “Forming knowledge” (clause 2.2.3) |
| Reduction of repeated questions | A practical consequence of “Retaining context” and “Providing intelligent assistance” |
| Development of ideas | “Developing ideas” (clause 2.2.4) |
The pattern visible in this table is that the expected results are not a new, separate list — they are the measurable, verifiable version of the purposes formulated in Section 2. For example, “Reduction of repeated questions” is not an abstract idea but a practically verifiable indicator: if MindRelay is working well, N.I.R.A. should not ask a User again for information previously provided (for example, about their interests or a project) (further detail — clause 4.5 of document MR-006, “Reducing repeated questions”).
This list, by contrast, consists of concrete technical steps for the near future. Let us consider each individually.
Currently, the control panel (clause 5.2.5) is accessible only through a web browser. The absence of a mobile version limits the author’s (or future organisational Users’, clause 9.3.1) ability to monitor the system while travelling, away from a computer. A push-notification system is directly connected to this — it is needed so that the author is immediately informed when a significant event occurs (for example, a new request or a security notice, clause 10.5 of document MR-007).
As described in clause 6.4, video files are currently analysed by extracting a single frame via OpenCV. This is a simplified approach, since one frame cannot convey the full content of a video. Planned expansion proceeds in two directions: extracting multiple frames (covering various moments of the video) and voice transcription (converting the video’s audio track into text, likewise via OpenAI Whisper). Once this improvement is more fully implemented, a video message will be processed just as fully as an image or a voice message.
This function is the Operator’s right to join a dialogue in person at any time and respond in place of N.I.R.A. (full legal basis — clause 4.4 of document MR-002, “Participation of the Operator”). Technically, this function is implemented in the config/ package (manual_takeover.json) and in the bot core, but it has not yet been fully tested and remains an area requiring improvement in stability.
To reach Level 1 (“Personal Knowledge Operating System”) of the three-level development trajectory described in Section 4 (“Vision”), the control panel must move beyond an interface that simply displays statistics and become a genuine control centre. This direction is the process of deepening, expanding and adding new capabilities to the current Dashboard functionality (clause 12.2).
A step towards Level 5 (“the Extended Ecosystem”) referred to in Section 4. Currently, the knowledge graph operates mainly within the person-project-topic triad (Section 7 of document MR-006); expansion means adding new node types and deeper levels of connection to this structure.
It is important to demonstrate clearly the link between these two lists: directions for development (13.3) are means of achieving the expected results (13.2), not ends in themselves. For example, “Expanding video analysis” (13.3.2) is not an end in itself — it serves the ultimate result of “Structuring of information” (13.2), because the more fully a video is analysed, the more accurately structured the resulting information becomes.
Bearing this principle in mind, the question applied when assessing any new direction for development is: which of the five expected results in clause 13.2 does this step serve? If no answer can be found, that direction may signal a drift away from MindRelay’s core mission (Section 3).
It is not by chance that this Section is placed near the end of the document — a philosophy section typically serves as a concluding statement that unites, and underlies, all the preceding sections (purpose, mission, vision, architecture, history, current status, future plans). In other words, if Sections 2–13 answer the questions of “what” and “how”, this Section answers the question of “why, ultimately, this way”.
The caveat referred to in Section 8 (“Core principles”) needs to be restated here, now with a more precise formulation: this is the project’s product-level philosophy. Clause 17.2 of document MR-005 addresses an entirely separate data-level philosophy — it explains the balance of ownership between the User and MindRelay: the User is entitled to their original information, while MindRelay is entitled to the generalised knowledge formed as a result of processing that information (full explanation — Section 10 of document MR-006, “Ownership of the knowledge base”).
To avoid confusing these two philosophies, let us clearly distinguish which question each answers:
| Product philosophy (this Section) | Data philosophy (MR-005 §17.2) | |
|---|---|---|
| Question | What is MindRelay for? | What right do the User and the system have over the data? |
| Content | The essence of connecting information and forming knowledge | The balance of ownership, the limits of the right to deletion |
| Scope | The project’s overall direction, its mission | Specific legal/technical matters |
“MindRelay’s purpose is not the mere storage of information. The project is directed at identifying connections between pieces of information and forming, on that basis, new knowledge, understanding and ideas.”
Let us break this statement down — every word carries weight. “not the mere storage of information” — it matters that the statement begins with a negation: the philosophy first clearly states what it wishes to avoid — MindRelay refuses to be a passive archive, a mere “data store”. “identifying connections” — this verb is given in an active, searching sense, not “storing” or “collecting” — this choice of words corresponds precisely to the automatic connection-identification mechanism described in clause 7.8 of document MR-006. “forming new knowledge, understanding and ideas” — this phrase sets three distinct concepts side by side: knowledge (a systematic, structured fact), understanding (a deeper, contextual meaning), and ideas (a new, synthesised suggestion).
This philosophical statement is not an isolated sentence — it is the knot of a single thread running from the beginning to the end of this document: with the mission in Section 3 (“connecting information and turning it into knowledge”) — almost the same idea, merely repeated in a deeper, explanatory form; with the vision in Section 4 (the “second brain” platform) — this philosophy justifies why that distant future level is needed; with the principles in Section 8 (“Knowledge formation”, “Connecting information”) — the operational, everyday manifestation of this philosophy; with the distinctiveness in Section 10 (“not an ordinary chatbot”, “not an ordinary information store”) — the philosophy proved through negation.
The significance of this philosophical statement is not merely declarative — it can be applied as a concrete test for evaluating any development decision within the project. If a new feature or change improves only the retention of information, but does not serve the identification of connections or the formation of knowledge, that feature may be regarded as not fully consistent with MindRelay’s philosophy. This very principle was applied practically in clause 13.4 (“The relationship between expected results and directions for development”).
The author, the owner of the idea, and the sole developer of the project is Ernat Kalkoz.
A fact mentioned several times throughout this document is that MindRelay is not a project built by a team or an organisation, but a project independently built by one person, from 6 June 2026 (clause 11.2) to the present day. This circumstance directly affects several characteristics of the project, which can be observed at various points in this document:
| Consequence of the sole developer | Where it is shown in this document |
|---|---|
| The pragmatism of architectural choices (Flask’s lightness, a frontend without a framework) | clauses 5.1, 6.1.2, 6.2.1 |
| A high pace of development, but a frequent need for structural revision | clauses 11.5, 5.6 |
| The project arising from the author’s personal need (dyslexia, unifying messengers) | clause 11.2.2 |
| The “project owner” category being the first, principal User | clause 9.2.1 |
The author simultaneously occupies several roles within the project: Developer — all the code, architecture, and architectural decisions; Operator — the person managing the Platform, as defined in the MindRelay Terms of Use (MR-002); First User — the real person who was the system’s original, measurable design target (clause 9.2.1); Curator — the person able to intervene directly in dialogues through the “takeover” function (clause 13.3.3), overseeing N.I.R.A.’s decisions.
This Charter is a document intended to provide general, explanatory information about the project, and it does not therefore repeat the author’s full legal status, jurisdiction, or a table of official contact details. The official, legally authoritative version of this information is located here:
Clause 3.9 of the MindRelay Terms of Use (MR-002), “Information about the Operator”
That clause sets out, in tabular form and with official wording, the Operator’s full name, legal status (natural person), jurisdiction (Republic of Kazakhstan), e-mail address, and languages of communication.
Any questions, comments or corrections relating specifically to this Project Charter (MR-008) may be sent to:
ernat.konirat@gmail.com