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, Data17 модулів

Система тегів виводу

Фреймворк використовує стандартизовані теги для структурування відповідей. Це прямий аналог реальних IC-стандартів:

//TSUKUYOMI:      → системні повідомлення фреймворку
//RESULT:         → основні аналітичні висновки (з атрибуцією джерел)
//QUERY:          → запити на уточнення або додаткові дані
//ANOMALY:        → статистичні викиди і аномальні патерни
//CRITICAL:       → часочутлива інформація (потребує негайної уваги)
//FLASH:          → термінові звіти (найвищий пріоритет)
//PRIORITY:       → пріоритетні висновки
//CLASSIFICATION: → мітки рівня чутливості інформації
//DISCLAIMER:     → обмеження і застереження щодо даних
//AMATERASU:      → персоналізовані комунікації від personality core

Чому це важливо для OSINT-аналітика?

Без стандартних тегів висновки AI — це суцільний текст. Теги дозволяють:

  1. Швидко сканувати вивід (шукати //CRITICAL замість читати все)
  2. Автоматично парсити результати скриптами
  3. Передавати матеріали колегам у зрозумілому форматі

Управління сесіями

Одна з найцінніших функцій 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.