# Том 14. Управление программой и единая архитектурная рамка

> Соответствует Тому 0 «Комплексного технического задания второго уровня» (KTU-II) и сквозным требованиям Частей II–V.

## 14.1. Назначение тома

Настоящий том устанавливает единые правила проектирования, управления и приёмки национальной интеллектуальной промышленной и ресурсно-экономической цифровой среды **Digital Kazakhstan Experience / KazResource OS**.  
Без утверждения данного тома ни одна команда не приступает к промышленной разработке.

Цель — исключить фрагментацию:
- Unreal не должен остаться «красивой демкой»;
- frontend — отдельным порталом;
- AI — отдельным чат-ботом;
- SCADA — отдельной телеметрией;
- data — отдельным хранилищем;
- инвестиции — Excel-моделями;
- гос. кабинеты — изолированными витринами.

Все компоненты — части одной архитектуры с единой идентификацией, шиной событий, графом знаний, AI-оркестрацией и безопасностью.

---

## 14.2. Обязательные результаты программы

Исполнитель должен разработать и утвердить:

1. Видение целевого продукта (Product Vision).
2. Карту заинтересованных сторон (Stakeholder Map).
3. Карту государственных и промышленных процессов (Process Map).
4. Принципы архитектуры.
5. Границы системы (Scope & Context Diagram).
6. Перечень внешних систем (External Systems Catalog).
7. Контекстную диаграмму (System Context).
8. Функциональную декомпозицию.
9. Карту возможностей платформы (Capability Map).
10. Карту доменов (Domain Map).
11. Карту потоков данных (Data Flow Map).
12. Модель управления программой.
13. Модель принятия архитектурных решений (ADR).
14. Реестр технических решений.
15. Реестр ограничений.
16. Реестр рисков.
17. Матрицу ответственности (RACI/RASCI).
18. Общий план релизов (Release Roadmap).
19. Процесс управления изменениями.
20. Процесс управления требованиями.

---

## 14.3. Архитектурные принципы

| № | Принцип | Расшифровка | Контроль |
|---|---------|-------------|----------|
| 1 | Одна сущность — один идентификатор | Каждый актив, документ, объект, скважина, оборудование, лицензия, организация, проект имеет UUID + CID + национальный реестровый ID | Data Governance, Asset Registry |
| 2 | Однократное получение данных | Данные берутся из первичного источника один раз и переиспользуются всеми разрешёнными модулями | Integration Architecture, Event Bus |
| 3 | Разделение фактов и расчётов | `fact`, `operational`, `historical`, `model`, `forecast`, `ai_recommendation`, `demo` — не смешиваются, UI маркирует каждую цифру | Data Quality, Provenance |
| 4 | API-first | Любая функция доступна через управляемый API (OpenAPI/gRPC/GraphQL) с версионированием, идемпотентностью, rate limiting | API Gateway |
| 5 | Event-driven architecture | Критические изменения публикуются как события в NEB/IEL | Kafka/NATS, Event Catalog |
| 6 | Security by Design | Безопасность закладывается до кода: threat model, zero trust, segmentation, crypto | Security Council |
| 7 | Offline and sovereign operation | Критические функции работают on-premises / в национальных ЦОД без обязательной зависимости от публичного зарубежного облака | Edge, sovereign cloud |
| 8 | Модульность | Каждый модуль заменяется или масштабируется без перестройки всей системы | Modular monolith + microservices |
| 9 | Наблюдаемость | Каждый сервис, процесс, запрос, модель, интеграция контролируются: metrics, logs, traces | Observability Platform |
| 10 | Человек принимает критическое решение | AI — рекомендации; необратимые гос./фин./пром. решения — с human-in-the-loop | AI Council, RBAC |

---

## 14.4. Модель управления программой

### 14.4.1. Руководящий комитет

- Состав: представители Министерства ИИ и цифрового развития, Минэнерго, Минфина, Нацбанка, NPC, KazMunayGas, KazTransOil, KUT, ключевые инвесторы.
- Функции: стратегические решения, утверждение плана релизов, бюджет, приоритеты пилотов.

### 14.4.2. Архитектурный совет

- Состав: главный архитектор, domain architects, представители заказчика, независимый аудитор.
- Функции: утверждает архитектуру, ADR, отклонения, технические стандарты (KUT-RGP, JEC).

### 14.4.3. Совет по данным

- Функции: владельцы данных, качество, lineage, master data, классификация, доступность.

### 14.4.4. Совет по AI

- Функции: утверждает модели, агентов, промты, guardrails, сценарии применения AI, этические нормы.

### 14.4.5. Совет по промышленной безопасности

- Функции: контролирует взаимодействие платформы с АСУ ТП/SCADA, read-only политики, OT/IT segmentation.

### 14.4.6. Совет по кибербезопасности

- Функции: модель угроз, требования защиты, порядок реагирования, SOC, аудит.

### 14.4.7. Комитет по изменениям

- Функции: изменения объёма, сроков, бюджета, требований, архитектурных отклонений.

---

## 14.5. Процесс принятия архитектурных решений (ADR)

Каждое значимое решение оформляется как Architecture Decision Record:

```
ADR-NNNN
- Проблема / контекст
- Варианты (минимум 2)
- Выбранное решение
- Обоснование
- Последствия
- Риски и митигация
- Дата, автор, согласующие
- Статус: proposed / accepted / deprecated / superseded
```

Обязательные ADR:
1. Выбор L1/L2/L3-архитектуры (микросервисы vs модульный монолит vs serverless).
2. Выбор 3D-движка (Unreal + Cesium vs Unity vs web-native).
3. Выбор LLM/AI-стека (on-prem LLaMA vs GPT-4/Claude API).
4. Выбор графовой БД (Neo4j vs ArangoDB vs Dgraph).
5. Выбор Industrial IoT/Edge (KUT SCADA vs Siemens WinCC vs Ignition).
6. Выбор блокчейн/нотариуса (MONOLITHAR vs Corda vs гиперлерджер).
7. Выбор цифровой валюты settlement (NPC Digital Tenge vs KUT Digital Bank).
8. Выбор модели контрактования / JV / IP.

---

## 14.6. Реестры программы

### 14.6.1. Реестр технических решений

| ID | Решение | Область | Статус | ADR | Владелец |
|----|---------|---------|--------|-----|----------|
| T-001 | Unreal Engine 5.4 + Cesium + Pixel Streaming | 3D/Viz | accepted | ADR-002 | Unreal Lead |
| T-002 | FastAPI + PostgreSQL + TimescaleDB + Neo4j | Backend/Data | accepted | ADR-001 | Solution Architect |
| T-003 | KUT HMI/SCADA + OPC-UA/MQTT Edge | OT | proposed | ADR-005 | OT Lead |
| T-004 | MONOLITHAR (PoEx) + ARKHETHOR / РВА-КЗ | Blockchain/Finance | proposed | ADR-006 | Blockchain Lead |
| T-005 | NPC Digital Tenge testnet + KUT Digital Bank bridge | CBDC | proposed | ADR-007 | Financial AI Lead |
| T-006 | LLaMA-3/GPT-4/Claude + LangGraph + RAG | AI | accepted | ADR-003 | AI Lead |

### 14.6.2. Реестр ограничений

| ID | Ограничение | Влияние | Митигация |
|----|-------------|---------|-----------|
| C-001 | Нет прямого управления оборудованием из демо | Функциональность | read-only, DMZ, simulation mode |
| C-002 | Реальные CAD/P&ID требуют NDA | 3D-детализация | Использование типовых/открытых моделей + LOD |
| C-003 | Цифровой тенге — пилот НБК, не production | Финансовые потоки | testnet, mock-кошельки, дисклеймер |
| C-004 | Гос. реестры недр — доступ по разрешению | Data | sandbox-реплики, анонимизация |
| C-005 | KazResource OS/MONOLITHAR/ARKHETHOR — в стадии согласования | Блокчейн/токены | mock-интеграции, roadmap согласования |

### 14.6.3. Реестр рисков

| ID | Риск | Вероятность | Влияние | Статус | Митигация |
|----|------|-------------|---------|--------|-----------|
| R-001 | Недостаточная производительность Pixel Streaming на планшете | Средняя | Высокое | мониторинг | LOD, bitrate, edge rendering, fallback 2D |
| R-002 | Галлюцинации AI при ответах министру | Средняя | Высокое | мониторинг | RAG, confidence, guardrails, fallback |
| R-003 | Утечка/подделка OT-данных | Низкая | Критическое | мониторинг | read-only, data diode, DMZ, audit |
| R-004 | Задержки интеграции с гос. реестрами | Средняя | Среднее | мониторинг | synthetic data, mapping, sandbox |
| R-005 | Изменение нормативной базы цифровых активов/CBDC | Средняя | Высокое | мониторинг | правовой мониторинг, fallback scenarios |

---

## 14.7. Матрица ответственности (RASCI)

| Роль / Деятельность | A | R | S | C | I |
|---------------------|---|---|---|---|---|
| Архитектурная рамка | Заказчик | Главный архитектор | AI/OT/Data/UX/Unreal leads | Юристы, аудитор | Все команды |
| Пилотные данные | Заказчик/оператор | Data Lead | OT Lead | Геологи, инженеры | AI, Unreal |
| AI-агенты | AI Council | AI Lead | ML Engineers | UX, Legal, Domain experts | Testers |
| 3D-сцена | Unreal Lead | 3D Artists | GIS, OT | UX, AI | Product Owner |
| Интеграции | Integration Lead | Integration Engineers | Domain owners | Security, Architects | Testers |
| Безопасность | Security Council | CISO/Security Lead | DevOps, OT, AI | Compliance, Legal | All |
| Финансовая модель | Финансовый совет | Financial AI Lead | Экономисты, Data | Аудитор | Investors |

---

## 14.8. План релизов

| Фаза | Сроки | Цель | Артефакты |
|------|-------|------|-----------|
| R0. Foundation | М0–М2 | Архитектура, стандарты, инфраструктура, команды | ADR, CI/CD, sandbox, data contracts |
| R1. Demo MVP | М3–М5 | Работающая демо-версия на планшете | 3D-сцена, AI-агенты, пилотный сценарий, приёмка |
| R2. Pilot OT | М6–М10 | Подключение одного реального промышленного кластера (read-only) | Edge, SCADA adapter, validated telemetry |
| R3. Sector Rollout | М11–М18 | Нефтегазовая отрасль: нефть, газ, переработка, транспорт | Sector twin, national dashboard |
| R4. Cross-Sector | М19–М30 | Горнодобыча, энергетика, ВИЭ, металлургия | Multi-sector knowledge graph |
| R5. National Scale | М31–М48 | Все утверждённые регионы и отрасли, интеграция с гос. кабинетами | National Situation Center |
| R6. Export / JEC | М36+ | KazResource OS как экспортируемая платформа, JEC, стандарты | IP transfer, international pilots |

---

## 14.9. Управление изменениями

1. Запрос на изменение (CR) — Jira/ServiceDesk.
2. Анализ влияния на архитектуру, сроки, бюджет, риски.
3. Решение Комитета по изменениям.
4. Обновление ADR, требований, плана релизов, приёмочных критериев.
5. Реализация, тестирование, приёмка.
6. Уведомление заинтересованных сторон.

---

## 14.10. Управление требованиями

- Единый реестр требований (Jama/Doors/Confluence + Git).
- ID требования: `REQ-<domain>-<NNNN>`.
- Трассировка: Стратегическая цель → бизнес-требование → функциональное → архитектурный компонент → модуль → тест → акт приёмки.
- Шаблон: ID, название, описание, критерий приёмки, приоритет, источник, owner, статус, версия.
- Запрещены неизмеримые формулировки: «быстро», «современно», «передовой AI», «надёжная защита».  
  Правильно: «Для 95% запросов время до первого токена ≤ 3 с, полный ответ ≤ 500 слов — ≤ 15 с».

---

## 14.11. Сквозные требования второго уровня

### 14.11.1. Единая трассируемость

```
[Стратегическая цель] → [Бизнес-требование] → [Функциональное требование] → [Архитектурный компонент] → [Программный модуль] → [Тест] → [Акт приёмки]
```

### 14.11.2. Управление конфигурацией

Версионируются: код, инфраструктура, модели данных, онтология, API, AI-промты, AI-модели, 3D-активы, сцены, отчёты, нормативные правила, тесты.

### 14.11.3. Суверенность и переносимость

- On-premises / национальный ЦОД.
- Экспорт данных в открытых форматах (GeoJSON, IFC, CSV, Parquet, RDF).
- Нет необратимой зависимости от одного публичного облака.
- Работоспособность при ограничении внешних сервисов.

### 14.11.4. Независимый технический аудит

До промышленной приёмки:
- архитектурный аудит;
- аудит исходного кода;
- аудит кибербезопасности;
- аудит AI;
- аудит данных;
- аудит промышленной безопасности;
- нагрузочное тестирование;
- аудит модели сопровождения.

---

## 14.12. Требования к содержанию каждого тома

Каждый технический том должен содержать:

1. Цель.
2. Область действия.
3. Термины и определения.
4. Заинтересованные стороны.
5. Функциональные требования.
6. Нефункциональные требования.
7. Архитектуру.
8. Компоненты.
9. Интерфейсы.
10. Данные.
11. Интеграции.
12. Безопасность.
13. Ошибки и исключения.
14. Производительность.
15. Масштабирование.
16. Мониторинг.
17. Тестирование.
18. Приёмку.
19. Эксплуатацию.
20. Риски.
21. Ограничения.
22. Зависимости.
23. Команду.
24. Сроки.
25. Стоимость / оценку.
26. Обязательные схемы.
27. Обязательные таблицы.
28. Обязательные прототипы.
29. Обязательные исходные материалы.
30. Формальные результаты.

---

## 14.13. Итоговая цель программы

Система должна быть одновременно:
- **впечатляющей** для руководителя государства;
- **прозрачной** для инвестора;
- **полезной** для инженера;
- **безопасной** для промышленного предприятия;
- **технически доказуемой** для профессионального аудитора.