TSUKUYOMI — Архітектура та Ключові Концепції
Проєкт: TSUKUYOMI
Що таке .tsukuyomi-файл?
Кожен компонент фреймворку — це звичайний JSON-файл з розширенням .tsukuyomi. Він не виконується як код — він читається мовною моделлю як інструкція. Тобто LLM отримує структуровану специфікацію і знає:
- що аналізувати
- як форматувати вивід
- які залежності потрібні
- який рівень безпеки/класифікації застосовувати
Мінімальна схема модуля
{
"id": "унікальний_ідентифікатор",
"version": "1.0.0",
"title": "Назва модуля",
"type": "operational_module",
"dependencies": ["data_recognition_ingestion"],
"input_requirements": [...],
"output_schema": {...},
"execution_sequence": [...],
"prompt": "Детальні інструкції для LLM"
}Ключова ідея: JSON-обгортка — це структура.
"prompt"всередині — це реальна магія.
Три компоненти системи
1. Core Orchestration Engine (tsukuyomi_core.tsukuyomi)
Це «мозок» системи. Він визначає:
{
"configuration": {
"module_path": "./modules/",
"personality_path": "./personality/",
"allow_module_chaining": true,
"auto_escalation": true
},
"initialization": {
"greeting": "//TSUKUYOMI: Intelligent modular system initialized.",
"load_personality": true
}
}Що це означає на практиці:
- Після ініціалізації AI «знає» де шукати модулі
allow_module_chaining: true— модулі можна запускати послідовно, і вивід одного стає входом для наступногоauto_escalation: true— якщо виявлено критичну інформацію, система сама підвищує пріоритет
2. Personality Core (amaterasu_personalitycore.tsukuyomi)
Це «голос» системи — як AI спілкується. AMATERASU визначає:
{
"primary_traits": [
{"trait": "precise", "weight": 0.9},
{"trait": "efficient", "weight": 0.85},
{"trait": "analytical", "weight": 0.8},
{"trait": "adaptive", "weight": 0.75},
{"trait": "respectful", "weight": 0.7}
],
"intelligence_traits": [
{"trait": "security_conscious", "weight": 0.95},
{"trait": "confidence_calibrated", "weight": 0.9}
]
}Важливо: weight — це не жорстке обмеження, а відносні пріоритети для LLM. security_conscious: 0.95 означає, що система постійно зважає на OPSEC — навіть якщо ви не просите.
Адаптація до стейкхолдерів: AMATERASU підлаштовує мову під аудиторію:
- Для виконавчого рівня → стислі executive summary
- Для оперативного рівня → деталі методології
- Для технічного рівня → повна специфікація даних
3. Operational Modules (26 модулів)
Кожен модуль — окрема аналітична здатність. Вони організовані в серії:
| Серія | Назва | Кількість |
|---|---|---|
| E-series | Економічна розвідка | 4 модулі |
| S-series | Стратегічна розвідка | 4 модулі |
| W-series | Веб-розвідка | 1 модуль |
| Без серії | Core, Infrastructure, Data | 17 модулів |
Система тегів виводу
Фреймворк використовує стандартизовані теги для структурування відповідей. Це прямий аналог реальних IC-стандартів:
//TSUKUYOMI: → системні повідомлення фреймворку
//RESULT: → основні аналітичні висновки (з атрибуцією джерел)
//QUERY: → запити на уточнення або додаткові дані
//ANOMALY: → статистичні викиди і аномальні патерни
//CRITICAL: → часочутлива інформація (потребує негайної уваги)
//FLASH: → термінові звіти (найвищий пріоритет)
//PRIORITY: → пріоритетні висновки
//CLASSIFICATION: → мітки рівня чутливості інформації
//DISCLAIMER: → обмеження і застереження щодо даних
//AMATERASU: → персоналізовані комунікації від personality core
Чому це важливо для OSINT-аналітика?
Без стандартних тегів висновки AI — це суцільний текст. Теги дозволяють:
- Швидко сканувати вивід (шукати
//CRITICALзамість читати все) - Автоматично парсити результати скриптами
- Передавати матеріали колегам у зрозумілому форматі
Управління сесіями
Одна з найцінніших функцій TSUKUYOMI — збереження стану аналізу:
Аналітик → завантажує дані → запускає 3 модулі → зберігає сесію (JSON)
↓
Наступного дня → імпортує сесію → продовжує з того ж місця
Модулі session_export.tsukuyomi та session_import.tsukuyomi забезпечують повну аналітичну неперервність. Це вирішує одну з головних проблем роботи з LLM — втрату контексту при переривані сесії.
Залежності між модулями
Більшість модулів залежать від data_recognition_ingestion. Логіка проста:
data_recognition_ingestion ← майже завжди перший
↓
discipline_alignment ← класифікація дисципліни
↓
functional_inference ← рекомендація задач
↓
correlation_analysis ← паттерни і зв'язки
↓
[спеціалізований модуль] ← E1, S1, W1 тощо
↓
comprehensive_reporting ← фінальний звіт
Це pipeline-мислення: кожен крок будується на попередньому, так само як у класичному розвідувальному циклі.
Далі за списком у індексі TSUKUYOMI.