# Foundations of Vilnism

## Відкрита дослідницька платформа для проєктування людських спільнот

**Версія:** 0.13
**Статус:** концептуальна чернетка
**Формат:** Canon as Code
**Мова:** українська

-----

## Журнал змін

### 0.12 → 0.13

Версія 0.13 додає **колективний механізм компіляції технологічного дерева**, спільний Civilization Simulation Runtime та зв'язок із TOS distributed compute.

Додано:

- **Forum as Human R&D Layer** — кожний `KnowledgeGap`, технологічний вузол або критичний dependency може мати прив'язану тему, RFC, bounty, prototype record, test plan і replication history.
- **Evidence lifecycle для технологій** — `OPEN_GAP → PROPOSED → DOCUMENTED → PROTOTYPED → LAB_TESTED → FIELD_TESTED → INDEPENDENTLY_REPLICATED → VERIFIED`, без автоматичного підвищення статусу через популярність автора.
- **Game-first bootstrap** — створення Civilization Simulation Game може бути першою великою публічною ціллю спільноти; щоб побудувати реалістичну гру, спільнота колективно заповнює й перевіряє технологічний граф.
- **One Simulation Engine** — відеогра, headless Monte Carlo/agent simulation, governance stress-test і digital-twin sandbox є різними режимами одного runtime, а не чотирма несумісними моделями.
- **TOS as civilization runtime** — TOS надає Resource Graph, Scenario/Simulation execution, task dispatch, audit, settlement snapshots та інтерфейс до локального/розподіленого compute.
- **Voluntary distributed compute** — симуляції можуть виконуватися локально, у TOS Private Grid або через майбутній Global Compute Exchange; жоден вузол не віддає ресурси приховано або без явного opt-in.
- **Future Frontier** — технології майбутнього не вилучаються з гри: verified reality, engineering knowledge, research, theoretical, speculative і fictional layers мають різний epistemic status та різну невизначеність у симуляції.
- **Reality → Game → Reality loop** — реальні поселення дають telemetry та field evidence; симуляція й людські стратегії знаходять нові варіанти; результати повертаються на Forum/Labs для фізичної перевірки.

### 0.11 → 0.12

Версія 0.12 перетворює Technology Ladder і Civilization Graph з переважно описових моделей на **Executable Civilization Graph** — машинозчитуваний граф, у якому реальні ресурси, компетенції, інструменти, виробничі процеси, пристрої та інфраструктура пов'язані явними залежностями.

Додано:

- **Civilization Technology Stack L0–L7** — функціональні технологічні рівні від survival і ремесла до автономного та advanced виробництва; рівні є capability-профілем, а не історичною шкалою.
- **Graceful Technological Degradation** — кожна критична функція повинна мати відомий нижчий режим, альтернативний фізичний принцип або чесно позначену точку незворотної залежності.
- **Dependency-complete device standard** — для критичних пристроїв описуються матеріали, інструменти, навички, енергія, витратні матеріали, тест результату, ремонт, заміни та шлях відновлення toolchain.
- **Executable Civilization Graph / Digital Twin** — реальні запаси, люди, потужності та інфраструктура можуть підсвічувати доступні/недоступні технології й single points of failure.
- **Knowledge Gap як first-class object** — якщо шлях від базових ресурсів до технології не описаний або не перевірений, система не приховує це, а створює явний gap.
- **Reality ↔ Simulation Loop** — Civilization Simulation Game використовує ту саму схему залежностей, що й реальний Civilization OS; симуляція шукає точки відмови, але не отримує нормативної влади.
- **Civilization Simulation Reality Bridge** — одна й та сама tech tree може працювати як гра, навчальний інтерфейс, цифровий двійник поселення та інструмент планування відновлення.

### 0.10 → 0.11

Додано **Pacifism, Self-Preservation & Conflict Retreat Doctrine**:

- мирний і неекспансіоністський характер Vilnism;
- залізне правило «не обмінювати незамінне на замінне»;
- пріоритет життя над територією та матеріальними активами;
- право на самозбереження без перетворення Canon на військову доктрину;
- Conflict Managed Retreat;
- статус displaced settlement;
- Non-Conquest Principle;
- civilization continuity over territorial continuity;
- явну межу: Canon не описує зброю, бойову тактику чи способи завдання шкоди.

### 0.9 → 0.10

Версія 0.10 розширює Civilization OS від загальної цивілізаційної стійкості до **all-hazards resilience**: поселення має бути спроєктоване не лише для втрати мережі чи економічного колапсу, а й для довготривалих кліматичних змін, природних катастроф, пандемій, геомагнітних бур, радіологічних/хімічних інцидентів та складених каскадів.

Додано:

- **Climate & Catastrophe Resilience Doctrine** — heat, drought, flood, wildfire, storm, sea-level rise, landslide, earthquake, tsunami, volcano, severe air pollution та compound events.
- **Settlement Habitability Envelope** — поселення повинно знати свої фізичні межі придатності: температура, вода, пожежний ризик, підтоплення, вітер, сейсміка, якість повітря, доступність евакуації та здатність відновлення.
- **No-single-location survival** — критичне знання, насіння, ключові інструменти, резервні копії та компетенції не можуть існувати лише в одному географічному вузлі.
- **Climate Migration / Managed Retreat Protocol** — заздалегідь визначені критерії, коли адаптація місця перестає бути раціональною і громада повинна переносити активи або населення.
- **Multi-hazard public health** — surveillance, WASH, isolation capacity, scalable care, medical stock rotation, mental-health continuity і privacy safeguards.
- **Food resilience** — seed diversity, local seed multiplication, soil fertility, low-input crops, protected cultivation, storage, preservation та резервні калорійні контури.
- **Infrastructure black-start and degraded modes** — вода, енергія, зв'язок, санітарія та виробництво повинні мати ручні/локальні режими запуску після повного знеструмлення.
- **Extreme Resilience Certification** — регулярні drills, red-team scenarios, recovery-time objectives, minimum reserves та незалежна перевірка.
- **Нові Розділи 44–46**; висновок перенумеровано на 47.

### 0.8 → 0.9

Версія 0.9 додає два довгострокові шари: **міжпоколінну безперервність** та **Historical & Mythological Governance Patterns**. Мета — не перетворити стародавні тексти на догму, а використовувати їх як джерело гіпотез із чіткою доказовою класифікацією.

Додано:

- принцип **«успадковувати метод, а не догму»**: друге покоління не зобов'язане підпорядковуватися Canon; воно має успадкувати право перевіряти, форкати й відкидати його;
- **Intergenerational Continuity Test** — успіх системи перевіряється тим, чи покоління, що виросло всередині communities, добровільно зберігає або покращує корисні принципи без індоктринації;
- evidence labels `[HIST]`, `[TEXT]`, `[MYTH]`, `[MAP]`, `[SPEC]` для історичних, текстових, міфологічних і реконструйованих governance-патернів;
- патерни Vajji/gana-sangha, task-specific assemblies, платонівської федеративної Атлантиди як текстового архетипу, prosperity-corruption watch, stepped Civilization Backup і епістемічної стриманості;
- уточнення щодо **Tartary**: картографічний термін не приймається як доказ єдиної прихованої держави; корисними для аналізу є реальні конфедеративні традиції Внутрішньої Азії;
- **нові Розділи 42–43**; попередній висновок перенумеровано на 44.

### 0.7 → 0.8

Версія 0.8 змінює масштаб Vilnism: від архітектури окремих автономних громад і їх федерації — до **відкритої Civilization OS**, що не нав’язує одну форму суспільства, а створює інфраструктуру для конкуренції, перевірки, успадкування й взаємодії багатьох добровільних моделей.

Додано:

- **Конкуренцію конструктивних рішень як цивілізаційний двигун**: суперечка має, де це можливо, переходити в альтернативу, прототип, тест, реплікацію та відбір за результатом.
- **Civilization Evolution Loop**: problem → proposal → prototype → test → replication → adoption → standard → new criticism.
- **Vilnism Civilization OS** як надрівень над Canon, Canon Studio, TOS, Science Commons, Settlement Network, Civilization Wiki/Graph і міжкомунальними протоколами.
- **Alliance without ideological alignment**: жодна партнерська громада не мусить приймати Canon; Vilnism служить протоколом сумісності й накопичення досвіду.
- **Science Commons і Social Knowledge Compiler**: перетворення дискусій на RFC, протоколи, стандарти, open-source hardware/software і відтворювані результати.
- **Багатовимірну репутацію без тотального social score** та суворе розділення оцінки ідеї від оцінки здатності автора виконати проєкт.
- **Intercommunity Protocol**: мобільність людей, переносимість активів, міжкомунальні договори, joint ventures, resource/talent/capital matching і federated settlement network.
- **Project Marketplace / Capital Layer** з принципом заборони процентного боргу й підтримкою equity, cooperative ownership, profit/revenue sharing, grants, pre-purchase та безпроцентних позик.
- **Civilization Reproducibility Index, Civilization Backup і Civilization Graph** як довгострокові інструменти пам’яті, стійкості й відтворення технологічної цивілізації.
- **Нові Розділи 36–41**: Civilization OS; Constructive Competition; Science Commons; Reputation & Identity; Intercommunity Economy; Settlement Network & Civilization Continuity.
- **Розділ 36 «Висновок» перенумеровано на 42**.

### 0.6 → 0.7

Версія 0.7 розширює цивілізаційну стійкість від кризового governance до практичного стандарту автономності людини та відновлення базових технологічних функцій після втрати інфраструктури.

Додано:

- **Новий Розділ 35. Vilnism Survival Standard і протокол відновлення цивілізації** — VSS як відкритий стандарт базових survival-функцій і пристроїв; VCRP як драбина від першої години виживання до табору, поселення, виробничої бази та сучасних технологічних контурів.
- **VSS Core** — відкритий каталог приблизно 30–50 функціональних модулів для води, вогню, тепла, укриття, енергії, світла, зв’язку, навігації, санітарії, медицини, їжі, інструментів і ремонту.
- **Інженерний принцип “Bring intelligence, not mass”** — переносити складні компоненти, які важко відтворити, а локальну масу й прості матеріали брати з середовища.
- **VSS-Light, Generator Core і VSS-Gravity** — saltwater/metal-air аварійне світло з чесним урахуванням витратного металу; універсальне механічне генераторне ядро; гравітаційне накопичення для малопотужних навантажень.
- **Technology Ladder** — дерево залежностей від простих інструментів і базових процесів до виробничих, електричних, інформаційних та сучасних технологічних систем.
- **Три режими відтворення** — Build from Kit, Build from Environment і Build the Toolchain.
- **Спіраль цивілізаційної освіти з дитинства** — від базового розуміння води, тепла, сигналізації та простих механізмів до спеціалізованої інженерної, медичної, аграрної та технологічної компетентності.
- **Стандарт відкритої документації, VSS-сумісності, метрик, польових симуляцій і Civilization Recovery Archive**.
- **Розділ 35 «Висновок» перенумеровано на 36**.

### 0.5 → 0.6

Версія 0.6 розширює Вільнізм від моделі автономних громад до формалізованої архітектури поліцентричної цивілізаційної мережі. Додано принципи федерації як протоколу, захист від ресурсної та технологічної гегемонії, біоміметичну архітектуру стійкості та криптографічний шар довіри й приватності.

Додано:

- **Новий Розділ 31. Федеративний протокол і поліцентрична цивілізація** — вичерпно делеговані повноваження, найнижчий достатній рівень, функціональні мережі, багаторівневе представництво без присвоєння суверенітету, тимчасові місії, інституційний TTL і відсутність незамінної столиці.
- **Новий Розділ 32. Захист від ресурсної, технологічної та економічної гегемонії** — Civilization Dependency Graph, dependency asymmetry, Essential Resource Protocol, civilizational commons, право на перевагу без права на гегемонію, відкриті критичні знання, безбанківське ризикове фінансування та маршрутизація капіталу без центрального власника.
- **Новий Розділ 33. Біоміметична архітектура цивілізації** — спеціалізація, гомеостаз, морфогенез через сигнали, модульність, різнорідне резервування, інституційний апоптоз, civilization stem capacity, розподілена імунна функція, bow-tie core, small-world зв’язність, нерезонансні цикли та динамічний баланс між ефективністю, стійкістю, адаптивністю й автономією.
- **Новий Розділ 34. Криптографічна довіра, приватність і мережеві принципи** — blockchain як доказовий, а не владний шар; permissioned ledgers; принцип «past immutable, future forkable»; мінімальне розкриття; розділення eligibility та voting identity; перевірюване таємне голосування; threshold control; локальне знання; selective transparency; privacy-preserving канали й forkability інфраструктури.
- **Розділ 31 «Висновок» перенумеровано на 35**.

### 0.4 → 0.5

Версія 0.5 розширює канон системною моделлю загроз, контрольованої деградації та відновлення, а також додає протоколи важких випадків, у яких базові принципи вступають у конфлікт.

Додано:

- **Новий Розділ 29. Модель загроз, деградація та відновлення системи** — критичні активи, суб’єкти загроз, класи захоплення, індикатори ранньої деградації, п’ять рівнів стану, контрольована деградація, red-team, стрес-тести, мирний поділ, відновлення й критерії втрати сумісності.
- **Новий Розділ 30. Протоколи важких випадків і конфлікту принципів** — матриця конфлікту цінностей, реальне право на вихід, внесок без трудового примусу, права дітей, донори, компетентність, приватність, AI, метрики, governance-втома, злочин, локальна автономія та ворожі форки.
- **Розділ 28 «Висновок» перенумеровано на 31** без зміни основного змісту.

### 0.3 → 0.4

Версія 0.4 не видаляє й не переписує попередній зміст — вона підіймає принцип автоматизації й мінімізації необхідної праці з побічної згадки (§4.8 у попередніх версіях) до явного, наскрізного й вимірюваного показника успішності всієї системи.

Додано:

- **§3, новий пункт KPI** — індекс необхідної зайнятості як один із головних показників успіху цивілізації.
- **§4.11 (новий)** — мінімізація необхідної зайнятості як кількісний, наскрізний показник: ціль через автоматизацію, а не зниження рівня життя; відстежується окремо для кожного з чотирьох режимів (§12.1); не суперечить збереженню цивілізаційної грамотності (§7.2) як резервної навички.
- **§11.1 (новий)** — гармонія технологічної складності й наближення до природи як єдиний напрямок розвитку, а не компроміс між двома цілями.

### 0.2 → 0.3

Версія 0.3 знову нічого не видаляє — додає новий розділ про зовнішній контакт і конфлікт та розширює три існуючі розділи на основі подальшого логічного аналізу: екстраполяції принципів документа до їхньої граничної форми (довговічна цивілізація, інший порядок сили) і сценарію, коли зовнішня сторона не погоджується на мирні умови.

Додано:

- **Новий Розділ 13. Протокол зовнішнього контакту та конфлікту** — кола прозорості ресурсів (§13.1), критерії правомірного вступу в конфлікт і виправданого відступу чи капітуляції (§13.2–13.3), публічність доктрини стримування (§13.4), захист від конфлікту інтересів у воєнному рішенні (§13.5), чесне визнання меж (§13.6).
- **Розширено Розділ 9. Економіка** — §9.6, багатовимірний облік ресурсів у фізичних величинах як альтернатива й доповнення до грошового обліку.
- **Розширено Розділ 15. Захист від концентрації впливу** — §15.5, обмеження влади, незалежні від тривалості життя учасника (кумулятивний обсяг рішень, а не лише час на посаді).
- **Розширено Розділ 19. TOS** — доданий модуль ресурсного дашборду (§19.2).
- **Розширено Розділ 20. AI як інтерфейс до знань** — §20.1, федеративна, а не централізована архітектура AI-інстансів по мірі масштабування мережі комун.

Усі наступні розділи (колишні 13–27 з версії 0.2) перенумеровані на 14–28 без зміни змісту.

### 0.1 → 0.2

Версія 0.2 не видаляла й не переписувала зміст версії 0.1 — вона додала новий розділ і розширила один існуючий розділ на основі детального логічного аналізу вразливостей, які будь-яка система такого масштабу мусить закрити ще на етапі проєктування, а не постфактум.

Додано:

- **Новий Розділ 14 (тоді). Захист від концентрації впливу** — конкретні механізми (жереб, термінові ліміти, анонімізоване рецензування пропозицій, розділення технічних повноважень, множинність методик порівняння комун), що не дозволяють неформальному впливу накопичуватись навіть за формально рівних прав.
- **Розширено Розділ 12. Цивілізаційна стійкість** — додано підрозділи про безпечний перехід між чотирма режимами (§12.3), деревоподібну архітектуру кризової координації (§12.4), механізм відкликання й ре-жеребкування координаторів (§12.5), протокол для гострих, часообмежених криз (§12.6) та механізм поділу груп при стійкій незгоді (§12.7).

-----

## Анотація

Вільнізм — це відкрита дослідницька платформа, метою якої є пошук, перевірка та розвиток моделей організації людських спільнот, що підвищують якість життя, свободу, здоров’я, осмисленість і цивілізаційну стійкість.

Вільнізм не проголошує завершеної істини й не пропонує єдиної універсальної форми суспільства. Він розглядає суспільний устрій як систему гіпотез, які можна описувати, моделювати, випробовувати в добровільних спільнотах, вимірювати, порівнювати, змінювати та відтворювати.

Практична архітектура складається з шести шарів:

1. **Ціннісне ядро** — свобода, гідність, здоров’я, відповідальність, відкрите знання і право на вихід.
1. **Жива конституція** — версіонований канон, представлений як код і відкритий до перевірки, обговорення та форків.
1. **TOS** — технологічна інфраструктура для знань, бюджетів, проєктів, голосувань, економіки та локальних сервісів.
1. **AI-інтерфейс** — пояснювальний і навігаційний шар, який допомагає працювати з системою, але не замінює людське судження.
1. **Культурний шар** — історії, мистецтво й медіа на кшталт *Light Illusions*, які створюють емоційну мову для складних ідей.
1. **Фізичні пілоти** — добровільні громади, кооперативи й поселення, де гіпотези перевіряються в реальному житті.

-----

-----

# 1. Вихідне питання

Більшість сучасних суспільних систем формувалися поступово. Вони успадковували старі інститути, юридичні конструкції, економічні стимули, культурні конфлікти й технологічні обмеження. Тому значна частина сучасного устрою не була спроєктована як цілісна система.

Вільнізм починається з питання:

> **Якби людство сьогодні проєктувало систему спільного життя з нуля, використовуючи сучасні знання, які принципи, інститути й технології воно обрало б?**

Кожен елемент суспільства має бути відкритий до трьох запитань:

- Яку реальну проблему він вирішує?
- Чи вирішує він її ефективно?
- Чи можна отримати кращий результат простішим, гуманнішим або стійкішим способом?

-----

-----

# 2. Цінності та емпіричні гіпотези

Вільнізм чітко розділяє два типи тверджень.

## 2.1. Ціннісні принципи {#s02-001}

Це свідомо обрані орієнтири, а не наукові факти:

- людська гідність має внутрішню цінність;
- свобода вибору є базовою умовою повноцінного життя;
- система існує для людини, а не людина для системи;
- знання мають бути максимально відкритими;
- влада має бути обмеженою, прозорою і підзвітною;
- людина не може бути власністю спільноти, держави, роботодавця чи кредитора;
- право на вихід є необхідним захистом від примусу.

## 2.2. Емпіричні гіпотези {#s02-002}

Це твердження, які мають перевірятися даними й пілотами:

- малі громади можуть мати нижчий рівень бюрократичного тертя;
- локальне виробництво частини їжі може підвищувати кризову стійкість;
- відкритий бюджет може підвищувати довіру;
- автоматизація рутинної праці може покращувати якість життя;
- версіонування правил може знижувати ризик прихованих змін;
- практична освіта може підвищувати автономність;
- локальні A/B-тести можуть бути ефективнішими за одночасну реформу всієї системи.

Жодна гіпотеза не стає догмою лише тому, що вона відповідає цінностям Вільнізму.

-----

-----

# 3. Головна мета і KPI

Головною метою є не максимізація ВВП, податків, кількості робочих місць чи споживання.

> **Головний орієнтир — довгострокове зростання якості життя, свободи, здоров’я, людського потенціалу та цивілізаційної стійкості.**

Система метрик може включати:

- фізичне й психічне здоров’я;
- тривалість здорового життя;
- доступ до житла, води, їжі, енергії, медицини й освіти;
- кількість добровільного вільного часу;
- суб’єктивне відчуття радості та осмисленості життя;
- рівень довіри;
- здатність впливати на рішення;
- доступ до інструментів і продуктивних ресурсів;
- стійкість до втрати інтернету, електрики, зовнішніх поставок або фінансової системи;
- рівень бюрократичного навантаження;
- реальну можливість вийти зі спільноти;
- якість середовища для дітей і наступних поколінь;
- **індекс необхідної зайнятості** (додано у v0.4) — частка часу дорослої людини, яку потрібно витратити на недобровільну працю заради виживання й підтримки базової інфраструктури; головний тренд-показник — послідовне зниження цієї частки через автоматизацію, а не через зниження рівня життя.
- **індекс відновлюваної автономності** (додано у v0.7) — наскільки швидко людина, мала група або громада може відновити критичні функції після втрати зовнішньої інфраструктури: безпечне укриття, воду, санітарію, базову енергію, зв’язок і локальне виробництво; детально визначається через VSS/VCRP у §35.

Метрики оцінюють систему, а не перетворюють кожну людину на об’єкт тотального контролю.

-----

-----

# 4. Фундаментальні принципи

## 4.1. Людина є метою, а не ресурсом {#s04-001}

Жодна інституція не має вищої цінності, ніж конкретне людське життя. Держава, ринок, корпорація, громада, релігія, технологія чи ідеологія мають сенс лише настільки, наскільки служать людям.

## 4.2. Тіло — перша територія свободи {#s04-002}

Людина має первинне право на власне тіло, здоров’я, відпочинок, рух, приватність і добровільну згоду.

## 4.3. Право на вихід {#s04-003}

Будь-яка добровільна система має передбачати реальну можливість її залишити: без фізичного примусу, довічного боргу, утримання даних, культового тиску чи втрати базової людської гідності.

## 4.4. Свобода без сваволі {#s04-004}

Свобода не означає право руйнувати свободу інших. Її межі визначаються конкретною шкодою, добровільними угодами та прозорими процедурами.

## 4.5. Відкрите знання {#s04-005}

Критичні знання про здоров’я, виживання, освіту, ремонт, виробництво, управління і відновлення базових функцій цивілізації мають бути максимально відкритими. Авторство зберігається, але монополія на критичне знання не повинна ставати інструментом поневолення.

## 4.6. Простота системи {#s04-006}

Правило, яке неможливо зрозуміти без професійного посередника, має вважатися потенційно дефектним. Складність допускається лише там, де вона об’єктивно необхідна.

## 4.7. Непомітна інфраструктура {#s04-007}

Добре спроєктована система не змушує людей постійно боротися з нею. Вода надходить, енергія працює, бюджет видно, правила зрозумілі, а більшість процесів не потребує нескінченних погоджень.

## 4.8. Технології звільняють увагу {#s04-008}

> **Машини автоматизують процеси; люди отримують більше часу на життя.**

Технологія має знімати рутину, небезпеку та безглузду працю, але не перетворювати людську увагу на товар.

## 4.9. Людський масштаб {#s04-009}

Як робоча гіпотеза автономна одиниця може мати до приблизно 10 000 жителів. Більші утворення доцільно будувати як федерації менших вузлів.

## 4.10. Відтворюваність {#s04-010}

Модель цінна не лише тоді, коли працює в одному унікальному місці, а коли її можна описати, перевірити, адаптувати та відтворити.

## 4.11. Мінімізація необхідної зайнятості як показник успіху (додано у v0.4) {#s04-011}

§4.8 формулює принцип якісно (“технології звільняють увагу”). Цей підрозділ робить його кількісним і наскрізним показником успішності всієї системи, а не побічною метрикою серед інших у §3.

- **Індекс необхідної зайнятості** (частка часу дорослої людини, обов’язкова для виживання й підтримки спільноти — вода, їжа, базова інфраструктура) відстежується як один із головних показників успішності цивілізації поряд зі здоров’ям і свободою, а не як другорядна деталь економіки (§9).
- Ціль — послідовне зниження цього індексу через автоматизацію рутинних, небезпечних чи одноманітних процесів, **а не через зниження рівня життя чи безпеки**. Зниження зайнятості за рахунок гіршого харчування, води чи медицини — не прогрес за цим показником, а його імітація.
- В ідеальній, технологічно зрілій формі необхідна праця у звичному сенсі може стати неактуальною; до досягнення цього стану частина праці (вода, їжа, будівництво, догляд) лишається потрібною, і показник відстежує *напрямок і швидкість* її скорочення, а не вимагає миттєвого нуля.
- Цей індекс відстежується **окремо для кожного з чотирьох режимів роботи** (§12.1): очікуваний мінімум у повному режимі значно нижчий, ніж в аварійному, де ручна праця неминуча — але тренд на зниження в межах кожного режиму (через кращі інструменти, збережені технології, локальну автоматизацію) лишається показником якості системи навіть у кризі.
- Автоматизація не повинна знецінювати цивілізаційну грамотність (§7.2): здатність людини самостійно добути воду, їжу чи укриття зберігається як резервна навичка навіть тоді, коли повсякденно ця праця повністю автоматизована — надлишковість знання є частиною стійкості (§12), а не суперечить економії зусиль.

## 4.12. Конкуренція конструктивних рішень як двигун розвитку (додано у v0.8) {#s04-012}

Vilnism не прагне усунути незгоду. Він прагне змінити форму, у якій незгода створює результат. Там, де проблема допускає паралельні добровільні експерименти, конкуренція за контроль над єдиним центром має поступатися конкуренції рішень.

> **Не конкурувати за владу. Конкурувати за краще рішення.**

Критика набуває найвищої конструктивної цінності, коли може перейти в proposal, fork, prototype, experiment, replication або documented failure. Перемога рішення не дає його автору влади над людьми; вона лише збільшує доказову вагу рішення.

## 4.13. Не правильний світ, а система створення кращих світів (додано у v0.8) {#s04-013}

Canon не є проєктом остаточного суспільства. Його мета — створити середовище, де багато добровільних моделей можуть народжуватися, співіснувати, порівнюватися, розділятися, об’єднуватися і замінювати одна одну без захоплення єдиного центру влади.

> **Не побудувати правильний світ. Побудувати систему, в якій людство може безперервно створювати кращі світи.**

## 4.14. Alliance without ideological alignment (додано у v0.8) {#s04-014}

Сумісність із мережею Vilnism не означає ідеологічної тотожності. Громада може використовувати протоколи, знання, software, science commons або marketplace, не приймаючи весь Canon. Право на fork і право на exit важливіші за брендове або доктринальне єднання.

## 4.15. Ідея оцінюється окремо від автора (додано у v0.8) {#s04-015}

Для наукових, технічних і канонічних пропозицій базовим режимом є blind review там, де це практично можливо. Репутація автора не повинна визначати істинність гіпотези. Водночас історія виконання може враховуватися, коли автор просить довірити йому гроші, людей, обладнання або операційну відповідальність.

-----

-----

# 5. Здоров’я як наука життя

Вільнізм доповнює медицину окремою дисципліною — наукою підтримання здорового життя.

Її основа:

- сон і ритми;
- щоденний рух;
- сила, витривалість, мобільність і координація;
- харчування;
- чиста вода;
- гігієна;
- профілактика;
- емоційна регуляція;
- здорові стосунки;
- вплив середовища;
- перша допомога;
- розуміння меж самолікування.

> **Застій руйнує; рух підтримує життя.**

Це культурна рекомендація, а не примусовий закон.

-----

-----

# 6. Їжа, земля і природна автономність

Їжа — не лише товар, а фундамент здоров’я, безпеки й автономії.

Кожна людина має отримати базове розуміння:

- походження їжі;
- роботи ґрунту;
- вирощування простих культур;
- збереження насіння;
- очищення води;
- зберігання та приготування продуктів;
- харчової якості;
- поведінки під час перебоїв поставок.

Мета не в тому, щоб усі стали фермерами, а в тому, щоб суспільство не втратило здатність прогодувати себе.

-----

-----

# 7. Освіта і цивілізаційна грамотність

## 7.1. Право дитини на цілісне виховання {#s07-001}

Кожна дитина має право на середовище, що розвиває:

- свободу волі;
- критичне мислення;
- емоційну зрілість;
- співпрацю;
- здорові межі;
- відповідальність;
- повагу і любов;
- самостійне навчання;
- розуміння тіла, природи й технологій.

Це обов’язок дорослих і спільноти створити можливості, а не обов’язок дитини відповідати жорсткому стандарту.

## 7.2. Цивілізаційна грамотність {#s07-002}

До повноліття людина має отримати можливість опанувати:

- воду, вогонь, укриття і їжу;
- першу допомогу;
- базові науки;
- логіку і роботу з доказами;
- навігацію;
- інструменти, ремонт і будівництво;
- енергію і зв’язок;
- цифрову грамотність;
- збереження інформації;
- вирішення конфліктів;
- сімейні та соціальні навички;
- виробництво базових речей;
- передачу знань далі.

Освіта може відбуватися через лабораторії, майстерні, ферми, проєкти, ігри, симуляції, наставництво й реальну участь у житті громади.

Починаючи з v0.7, практичне ядро цієї цивілізаційної грамотності деталізується у **Vilnism Survival Standard і Civilization Reboot Protocol (§35)**: від алгоритму першої години й базових VSS-модулів до Technology Ladder, що показує залежності між простими й складними технологіями.

> **Примітка до версії 0.2:** рівень реальної цивілізаційної грамотності кожного учасника — не другорядна деталь, а технічна передумова того, щоб механізми поділу груп при кризі (див. §12.7) були справедливим науковим експериментом, а не природним відбором за випадковим стартовим ресурсом. Слабкість у цьому розділі підриває надійність усієї архітектури кризової стійкості.

-----

-----

# 8. Культура і живе середовище

Закони задають межі. Культура створює повсякденне життя.

Громада має будувати середовище, де реальність цікавіша за нескінченний цифровий скролінг.

До культурної інфраструктури можуть належати:

- ярмарки;
- сезонні свята;
- дні ремесел;
- спортивні змагання;
- фестивалі винахідництва;
- відкриті сцени;
- музика і театр;
- спільні вечері;
- ритуали вдячності;
- локальна мода;
- традиції взаємодопомоги;
- публічне визнання корисного внеску.

Престиж має бути пов’язаний не лише зі споживанням, грошима чи популярністю, а з відкриттями, винаходами, навчанням інших, урожаєм, будівництвом, турботою, мистецтвом і науковими результатами.

-----

-----

# 9. Економіка

## 9.1. Економіка служить життю {#s09-001}

Економіка — це спосіб організації ресурсів, праці й обміну. Вона не повинна визначати людську цінність.

## 9.2. Гідна базова основа {#s09-002}

Учасники громади мають доступ до достатньої бази: житла, води, їжі, енергії, медицини, освіти, зв’язку, інструментів і безпечного середовища.

Це не означає абсолютної однаковості. Принцип полягає в тому, що ніхто не живе в розкоші завдяки системній нестачі іншого.

## 9.3. Заборона боргового рабства {#s09-003}

Борг не повинен ставати механізмом довічного контролю. Базові умови життя не можуть бути інструментом шантажу через непрозорі відсотки, штрафи або залежність.

## 9.4. Внутрішня і зовнішня економіка {#s09-004}

Громада може використовувати:

- внутрішню систему — взаємодопомогу, ресурсний облік, локальні одиниці чи бартер;
- зовнішню систему — легальну торгівлю, продаж продуктів і послуг, закупівлю металів, чіпів, ліків, інструментів та обладнання.

> **Взаємодія без поглинання.**

## 9.5. Успіх одного не є поразкою інших {#s09-005}

Людина може мати зовнішній бізнес або високий дохід. Приватний успіх не купує політичний вплив, але культура може заохочувати добровільний внесок у спільні проєкти.

## 9.6. Багатовимірний облік ресурсів (додано у v0.3) {#s09-006}

Гроші — соціально домовлена абстракція для обміну в умовах дефіциту й неповної інформації, і саме тому вона вразлива до маніпуляції (інфляція, спекуляція, борг). Внутрішній облік громади (§9.4) може спиратись на прямі, фізично вимірювані величини — енергію, воду, час кваліфікованої праці, рідкісні матеріали — паралельними рядами, без штучного зведення до єдиного числа.

Це не означає відмову від грошей як інструменту зовнішньої торгівлі (§9.4) — одновимірний облік самої лише енергії теж недостатній: він не відображає якісні відмінності (чистота води, цінність унікального знання чи мистецтва). Прозорий, публічно переглядуваний обмінний курс між вимірюваними величинами — ціль, до якої варто рухатись у TOS (§19), а не одразу вимога.

## 9.7. Заборона процентного боргу та альтернативний капітал (додано у v0.8) {#s09-007}

У межах канонічної економічної моделі договір боргу не може вимагати гарантованої додаткової виплати лише за плин часу користування principal. Позика повертає principal за погодженим графіком; адміністративні витрати можуть відшкодовувати лише реальні, прозорі й перевірювані витрати, а не прихований процент.

Це правило не забороняє ризикову участь у створеній цінності. Допустимими предметами окремих добровільних договорів можуть бути:

- equity / ownership participation;
- cooperative ownership;
- profit sharing і revenue sharing, де винагорода залежить від фактично створеного результату;
- grants і donations;
- pre-purchase / advance purchase;
- interest-free loans;
- інші форми, в яких ризик і винагорода описані прямо, а людина не стає заставою або власністю кредитора.

Громади можуть взаємодіяти із зовнішніми правовими та фінансовими системами лише настільки, наскільки це не змушує учасника або саму громаду порушувати це правило у власних добровільних договорах. Юридична реалізація завжди залежить від права конкретної юрисдикції.

-----

-----

# 10. Скарбниця і бюджет

Спільна скарбниця фінансує життєзабезпечення, резерви, будівництво, воду, енергію, освіту, медицину, лабораторії, майстерні, науку й кризове реагування.

Принципи:

- спільні кошти прозорі;
- приватні фінанси людей не є публічними;
- внесок не купує голоси;
- кожен проєкт має кошторис, команду, строки, метрики й звіт;
- кошти можна спрямовувати на конкретні проєкти;
- частина доходу може автоматично розподілятися між відкритими фондами;
- значні зміни проходять публічне обговорення.

Governance може працювати як внутрішній Kickstarter для води, енергії, житла, лабораторій та інших спільних проєктів.

-----

-----

# 11. Людський масштаб і архітектура

Поселення має проєктувати не лише будинки, а середовище:

- компактність;
- доступність основних місць пішки;
- центральний громадський простір;
- житлові зони;
- сади і ферми;
- майстерні й лабораторії;
- спорт;
- медицина;
- освіта;
- резервні системи води й енергії;
- автономна робота без інтернету.

Радіальна чи секторна структура, подібна до футуристичних моделей Жака Фреско, може бути однією з гіпотез, а не обов’язковим стандартом.

Якщо громада накопичила знання, інструменти та будівельні технології, базове житло нового учасника може створюватися як стандартний спільний процес.

## 11.1. Гармонія технології й природи як напрямок розвитку (додано у v0.4) {#s11-001}

Зростання технологічної складності інфраструктури й наближення до природного середовища — не суперечність, яку доводиться балансувати компромісом, а спільний напрямок, якщо слідувати індексу необхідної зайнятості (§4.11): чим глибше автоматизовано підтримку базових систем (вода, енергія, клімат), тим менше потреби в масштабній, ресурсоємній інфраструктурі, яка витісняє природне середовище — і тим більше простору лишається для збереження живого ландшафту навколо компактного поселення.

- Архітектурна й технологічна складність спрямовується на **непомітність** (§4.7) — розвинена інженерія має ставати менш видимою в повсякденному житті, а не більш присутньою.
- Пріоритет надається рішенням, що поєднують автоматизацію з природними процесами (наприклад, відновлювані локальні цикли води й енергії), а не рішенням, що замінюють природне середовище повністю штучним.

-----

-----

# 12. Цивілізаційна стійкість

## 12.1. Чотири режими роботи {#s12-001}

1. **Повний режим** — доступні інтернет і зовнішня інфраструктура.
1. **Локальний режим** — працює локальна мережа, глобальний зв’язок обмежений.
1. **Офлайн-режим** — локальні копії знань, ручний облік і місцева координація.
1. **Аварійний режим** — паперові протоколи, радіозв’язок, фізичні архіви й розподілені ролі.

## 12.2. Безпека {#s12-002}

Безпека будується навколо профілактики, медіації, запасів, медицини, зв’язку, евакуації, охорони критичної інфраструктури й цивільної підготовки.

У разі повного колапсу пріоритетом є не культ зброї, а організація, навички, взаємодопомога, вода, їжа, медицина, укриття і координація.

Практичний порядок відновлення цих функцій, вимоги до відкритих пристроїв, навчання й переходу від виживання до стабільного поселення визначаються VSS/VCRP у §35.

## 12.3. Безпечний перехід між режимами (додано у v0.2) {#s12-003}

Історичний досвід (від римського інституту тимчасового диктатора до статті 48 Веймарської конституції) показує: найвразливіший момент — не сам кризовий режим, а **перехід** до нього і, особливо, відсутність гарантованого повернення назад. Тимчасові надзвичайні повноваження мають системну тенденцію ставати постійними, якщо момент і критерій переходу залишені на розсуд конкретної людини в момент кризи.

Тому перехід між режимами (§12.1) підпорядковується таким правилам:

- **Тригери переходу визначаються заздалегідь, у спокійний час, а не оголошуються постфактум.** Критерії мають бути вимірюваними й перевірюваними незалежно (наприклад: підтверджена відсутність зв’язку з зовнішньою мережею протягом визначеної кількості днів, зафіксована кількома незалежними джерелами) — а не залежати від оцінки однієї людини чи групи в моменті.
- **Повернення до попереднього режиму відбувається автоматично**, коли умови, що викликали перехід, зникають, без окремого голосування “чи хочемо ми повернути стару систему”. Голосування про повернення — саме та процедурна щілина, де historically виникав спокуса залишитись у надзвичайному стані.
- Будь-яка розширена повноваження, що активується в режимах 3–4, автоматично звужується назад при поверненні до режиму 1–2, без потреби підтверджувати це рішенням наділеної повноваженнями особи.

## 12.4. Архітектура кризової координації (додано у v0.2) {#s12-004}

Для режимів 3–4 (§12.1), коли централізована координація через звичайні канали недоступна, застосовується деревоподібна структура малих груп — принцип, близький до історичного устрою малих міст і математично обґрунтований у теорії розподілених систем: складність координації зростає лінійно (не квадратично) відносно кількості учасників саме за такої архітектури.

Базова модель:

- Населення ділиться на первинні групи приблизно по 10 людей (сусідство, кілька родин поруч), для яких доступність фізичного контакту важливіша за точну чисельність.
- Кожна первинна група випадковим жеребом (не голосуванням і не за компетенцією) визначає координатора для суто організаційних питань. Жереб виключає стимул цілеспрямовано будувати вплив заради цієї ролі.
- Групи координаторів наступного рівня формуються з представників ~10 первинних груп, знову через жереб серед координаторів нижчого рівня.
- Процес повторюється до верхнього рівня — координаційної ради, що охоплює весь масштаб громади (~10 000 осіб).
- На верхньому рівні жереб визначає непарну кількість членів ради з окремою роллю модератора/арбітра розбіжностей між іншими членами ради.

Важливе уточнення: жереб визначає *справедливість шансу* отримати роль, але не гарантує *психологічну готовність* конкретної людини координувати саме в кризовій ситуації. Тому на кожному рівні жереб формує пул із кількох кандидатів (не одну людину), а сама первинна група, що делегує представника, робить остаточний вибір із цього випадкового пулу за ситуативною готовністю — зберігаючи антиконцентраційний ефект жеребу й водночас закриваючи ризик випадкового призначення психологічно неготової людини.

## 12.5. Відкликання та ре-жеребкування координаторів (додано у v0.2) {#s12-005}

Роль координатора не є посадою, яку можна утримувати за рахунок особистої симпатії групи чи навпаки втратити через неї. Відкликання відбувається виключно за об’єктивними, наперед визначеними критеріями результату в зоні відповідальності координатора — не за суб’єктивним “хтось комусь не подобається”.

- Кожна первинна група та кожен вищий рівень координації мають право ініціювати процедуру ре-жеребкування, якщо є вимірюване, задокументоване відхилення від погоджених задач у зоні відповідальності координатора.
- Ре-жеребкування не супроводжується соціальним осудом чи покаранням — це технічна процедура, а не суд над людиною. Причиною може бути об’єктивна непридатність до конкретного типу задач, а не провина.
- Відкликаний координатор повертається до звичайної ролі учасника первинної групи без втрати статусу чи довіри.

## 12.6. Протокол для гострих, часообмежених криз (додано у v0.2) {#s12-006}

Механізм паралельного тестування стратегій (§12.7) підходить для ситуацій, де є час на порівняння результатів. У гострій кризі (загроза життю в масштабі годин, а не тижнів) очікування результатів експерименту саме по собі може коштувати життів обом групам.

Для такого сценарію заздалегідь, у спокійний час, узгоджується запасний протокол типу “tie-breaker”: якщо консенсус групи координаторів не досягнутий протягом визначеного, короткого часового вікна, а загроза безпосередня, автоматично активується наперед прописане правило пріоритету (наприклад, пріоритет варіанту з найкоротшим часом виконання чи найменшою незворотністю наслідків при помилці) — а не рішення конкретної людини, ухвалене під тиском моменту.

## 12.7. Поділ груп при стійкій незгоді (додано у v0.2) {#s12-007}

Коли частина спільноти послідовно й обґрунтовано не погоджується зі стратегічним напрямком іншої частини (наприклад, пріоритет води проти пріоритету укриття), а дискусія на зборах не приводить до консенсусу, конфлікт вирішується не голосуванням “хто переміг”, а **поділом і паралельним випробуванням** — підхід, аналогічний принципу “exit over voice”: незгода вирішується розходженням, а не боротьбою за контроль над єдиним ресурсом.

- Поділ дозволяється лише за умови мінімальної, наперед визначеної кількості учасників у кожній з утворюваних груп — щоб рішення приймалось на рівні координаційної групи, а не окремою малою родиною з дітьми поодинці.
- Обидва варіанти залишаються під наглядом і в полі даних центральної координації навіть після поділу — це не розрив зв’язку, а паралельний, спостережуваний експеримент.
- Після завершення кризи чи визначеного періоду групи порівнюють результати відкрито, без осуду, і слабша стратегія переймає елементи сильнішої — так само, як конкуруючі наукові гіпотези уточнюють одна одну, а не знищують.
- Ця процедура — не заперечення єдності спільноти, а визнання того, що в умовах високої невизначеності диверсифікація стратегій підвищує шанс на виживання цілого понад те, що дав би єдиний, обраний наперед варіант.

-----

-----

# 13. Протокол зовнішнього контакту та конфлікту (новий розділ, додано у v0.3)

Право на вихід (§4.3) і принцип “взаємодія без поглинання” (§9.4) описують мирну взаємодію з іншими системами. Цей розділ прямо адресує сценарій, коли інша сторона — інша комуна, зовнішня держава, ворожа структура чи гіпотетично інша цивілізація — не погоджується на мирні умови. Мовчання канону про цей сценарій саме по собі є вразливістю: рішення, не продумані заздалегідь, ухвалюються під найбільшим тиском і найгірше.

## 13.1. Кола прозорості ресурсів {#s13-001}

Прозорість інформації про ресурси, можливості й стратегію градується за колом довіри, а не є універсально відкритою чи універсально закритою:

- **Усередині комуни** — повна відкритість (узгоджується з §19, TOS-дашборд ресурсів).
- **Із партнерськими комунами й союзниками** — відкритість за наперед погодженим двостороннім протоколом обміну.
- **З невідомою чи ворожою зовнішньою стороною** (інший порядок сили, інші бази, інша цивілізація) — режим повної секретності, непередбачуваності й раптовості вмикається без винятків.

Це не суперечність із принципом прозорості (§22, Відкрита критика) — прозорість є способом запобігання внутрішній концентрації влади, а не зобов’язанням розкривати вразливості перед стороною, що не поділяє тих самих правил.

## 13.2. Коли виправдано вступати в конфлікт {#s13-002}

Адаптація критеріїв *jus ad bellum* з традиції теорії справедливої війни, як перевіреного, а не вигаданого з нуля стандарту:

- **Правомірна причина** — виключно самозахист від реальної, задокументованої загрози, не превентивна дія “про всяк випадок”.
- **Останній засіб** — усі мирні канали (§13.1, протокол контакту) вичерпані й задокументовані до ухвалення рішення.
- **Пропорційність** — очікувана шкода від опору не перевищує шкоду від відступу чи капітуляції.
- **Розумна ймовірність успіху** — оцінюється заздалегідь погодженим, вимірюваним порогом (ресурси, чисельність, положення), а не суб’єктивним відчуттям координатора в моменті. Той самий ресурсний AI-аналізатор, що обраховує розподіл води й їжі (§19), застосовується до цієї оцінки з такою самою неупередженістю.

## 13.3. Коли виправдано відступати чи капітулювати {#s13-003}

Це не менш важливе, а часто важче рішення, ніж рішення про опір, і канон визнає його прямо: **коли попередньо погоджений поріг ймовірності успіху (§13.2) не досягається, відступ, евакуація чи капітуляція є легітимною, гідною стратегією, а не ганьбою.**

- Культурний шар (§21) відповідає за формування середовища, де ця стратегія психологічно прийнятна заздалегідь, а не вирішується в момент відчаю чи символічного спротиву під тиском емоцій.
- Рішення про відступ підпорядковується тому самому принципу, що й рішення про опір — заздалегідь відомому порогу, а не одноосібній волі координатора в моменті.

## 13.4. Публічність доктрини стримування {#s13-004}

Теорія конфлікту дає контрінтуїтивний, але добре обґрунтований результат: непередбачувані наміри провокують перевірку силою частіше, ніж стримують її. Тому:

- Загальні принципи (коли громада захищається, а за яких умов відступає) публічно відомі заздалегідь — двозначність тут є вразливістю, а не захистом.
- Конкретні ресурси й тактичні деталі (§13.1) лишаються засекреченими від зовнішньої невідомої сторони — секретна лише *міра сили*, не сама *доктрина рішень*.

## 13.5. Проти конфлікту інтересів у рішенні про війну {#s13-005}

Особа чи група, що ухвалює рішення про початок чи продовження конфлікту, не повинна отримувати особистої вигоди (статус, владу, ресурси) від самого факту конфлікту — той самий принцип, що й у §15.3 щодо технічної інфраструктури. Кризовий координатор (§12.4) не має преференційного доступу до трофеїв, статусу переможця чи розширених повноважень, що зберігаються довше, ніж триває сама криза (§12.3, автоматичне повернення режиму).

## 13.6. Чесна межа {#s13-006}

Людство не має перевіреного історичного прецеденту рівноправного контакту між принципово різними системами цінностей — колоніальна історія показує майже виключно поглинання сильнішим слабшого. Цей розділ не гарантує успішного результату конфлікту чи контакту; він гарантує лише, що рішення ухвалюються за заздалегідь узгодженою, а не імпровізованою в момент паніки логікою, і що структура ухвалення рішення сама не створює стимулу до конфлікту.

-----

-----

# 14. Справедливість і конфлікти

Базова модель:

- переговори;
- медіація;
- коло відновлення;
- арбітраж;
- апеляція;
- зовнішнє правове поле для серйозних правопорушень.

Арбітри не утворюють постійну касту влади. Ролі обмежені, підзвітні й за можливості ротаційні.

Мета — відновити справедливість і безпеку, а не максимізувати покарання.

-----

-----

# 15. Захист від концентрації впливу (новий розділ, додано у v0.2)

Формальна рівність прав не гарантує рівності фактичного впливу. Навіть у найменших, найдовірливіших спільнотах — включно з добре задокументованими історичними прикладами (кібуци, довготривалі комуни) — неформальна ієрархія за харизмою, красномовністю, стажем перебування чи технічною компетенцією виникає органічно, навіть за повністю рівних формальних часток і доброї волі всіх учасників. Мета цього розділу — не заперечити цю тенденцію силою волі чи деклараціями, а спроєктувати систему так, щоб концентрація впливу залишала публічний, легко видимий слід і не могла закріпитись без нього.

## 15.1. Проти впливу через красномовність і посаду {#s15-001}

- **Жереб (sortition)** для будь-якої ролі, що передбачає координацію, а не унікальну експертизу — модератори форуму, фасилітатори голосування, координатори кризових груп (див. §12.4). Жереб прибирає стимул цілеспрямовано будувати вплив заради здобуття ролі, бо роль не здобувається переконливістю.
- **Термінові ліміти без права на негайне переобрання** для будь-якої координаційної (не експертної) ролі. Лікар лишається лікарем за компетенцією; модератор форуму — ні.

## 15.2. Проти впливу через стаж і статус “старожила” {#s15-002}

- Обов’язкова ротація новачків у прості координаційні ролі з першого року участі — щоб тривалість перебування в спільноті сама по собі не ставала валютою впливу.
- Анонімізація пропозицій на етапі публічного обговорення (до моменту голосування): ідея оцінюється на форумі без імені автора, за аналогією з процедурою сліпого рецензування в науці. Це зміщує оцінку з “хто сказав” на “що сказано”.

## 15.3. Проти впливу через контроль над технічною інфраструктурою {#s15-003}

Той, хто фактично керує Canon Studio (§18) чи AI-інтерфейсом (§20), отримує непропорційний доступ до формування того, що спільнота бачить і обговорює — навіть за повної формальної рівності голосів. Захист:

- Технічна інфраструктура канону — відкритий код без ексклюзивного доступу на запис для жодної окремої людини; зміни проходять консенсусний merge через кількох незалежних, ротаційних мейнтейнерів (аналогічно розподіленим open-source проєктам), а не одноосібний контроль.
- AI-інтерфейс не має ексклюзивного каналу впливу на пропозиції чи голосування; його роль обмежена поясненням і навігацією (це вже зафіксовано в §19 версії 0.1, і цей розділ додає технічний механізм для дотримання цього принципу, а не лише декларацію).

## 15.4. Проти прихованого зсуву критеріїв “ефективної” моделі між комунами {#s15-004}

Коли дані з десятків комун порівнюються для визначення “ефективнішої” моделі (див. §25 про поширення канону), сам механізм порівняння стає новою потенційною точкою впливу: хто пише алгоритм порівняння і які метрики важать більше, той непомітно нахиляє напрямок розвитку всієї мережі.

- Порівняння ефективності моделей між комунами відбувається через множинні, незалежні, публічно змагальні методики, а не через одну централізовану платформу з єдиним алгоритмом — за аналогією з тим, як у науці конкурують кілька незалежних мета-аналізів, а не існує один “офіційний” висновок.
- Жоден автор методики порівняння не може бути одночасно автором моделі, яку ця методика оцінює найвище.

## 15.5. Обмеження влади, незалежні від тривалості життя (додано у v0.3) {#s15-005}

Термінові ліміти (§15.1) спираються на природну ротацію поколінь як неявний запобіжник. Це припущення варто зафіксувати явно, а не залишати мовчазним: якщо тривалість чи якість людського життя суттєво зміниться, сам механізм ротації через природну зміну поколінь перестає діяти як гарантія.

- Обмеження на координаційну владу визначаються **кумулятивним обсягом ухвалених рішень**, а не лише часом на посаді — це працює однаково незалежно від тривалості життя учасника.
- Незалежно від того, хто формально обіймає координаційну роль, періодично й примусово вводяться нові перспективи в процес ухвалення рішень (нові учасники, зовнішні аудитори, документовані контраргументи) — це страхує від застою мислення навіть тоді, коли сама особа лишається на позиції довше, ніж очікувалось на момент написання цього канону.

## 15.6. Що ці механізми не вирішують — і чому це чесно визнати {#s15-006}

Жоден з перелічених механізмів не усуває тенденцію до нерівномірного розподілу впливу повністю — це доведено математично: результати на кшталт теореми Ерроу показують, що жодна система голосування з більш ніж двома альтернативами не може одночасно задовольнити повний набір інтуїтивно справедливих критеріїв без вразливості до стратегічної поведінки. Мета цих механізмів — не досягти неможливого (нульового впливу), а зробити накопичення впливу максимально видимим, оборотним і дорогим для того, хто спробує його утримати нечесно, замість покладатись на довіру чи добру волю як єдиний захист.

-----

-----

# 16. Жива конституція

Конституція Вільнізму — це жива специфікація, але різні її частини мають різний рівень стабільності.

## 16.1. Майже непорушне ядро {#s16-001}

- людська гідність;
- добровільність;
- право на вихід;
- заборона власності на людину;
- прозорість влади;
- відкрите знання;
- право на критику;
- заборона купівлі політичної влади;
- підзвітність примусових механізмів.

## 16.2. Змінні норми {#s16-002}

- структура органів;
- процедури;
- бюджетні моделі;
- правила членства;
- механізми голосування;
- розподіл компетенцій.

## 16.3. Експериментальні регламенти {#s16-003}

- локальні проєкти;
- освітні програми;
- економічні моделі;
- інфраструктурні рішення;
- технологічні інструменти.

Зміни проходять цикл: проблема → гіпотеза → аргументи → ризики → локальний пілот або A/B-тест → дані → звіт → голосування → можливість відкату → архівування версії.

-----

-----

# 17. Canon as Code

Конституція і пов’язані документи зберігаються як відкритий код.

Базові властивості:

- текстові файли;
- Git-історія;
- коміти;
- pull requests;
- issues;
- теги версій;
- SHA-хеші;
- цифрові підписи;
- детерміноване складання;
- автоматична перевірка структури;
- переклади;
- форки;
- відтворювані збірки.

SHA-хеш дозволяє перевірити, що конкретна версія не була непомітно змінена.

Переклади пов’язуються з конкретною версією оригіналу, мають власний хеш, позначають неперекладені зміни й проходять людську перевірку.

-----

-----

# 18. Vilnism Canon Studio

Canon Studio — інструмент для роботи з живим каноном.

Можливі функції:

- навігація по статтях;
- редагування;
- порівняння версій;
- перевірка хешів;
- побудова релізів;
- переклади;
- залежності між документами;
- генерація вебверсії;
- експорт у Markdown, PDF та інші формати;
- пошук суперечностей;
- коментарі;
- пропозиції змін;
- карти понять;
- моделювання форків;
- локальне складання без центрального сервера.

Canon Studio не визначає «правильну ідеологію». Він забезпечує прозору роботу з версіонованими системами правил.

-----

-----

# 19. TOS як операційна система громади

Якщо канон відповідає на питання **«що ми вважаємо правильним?»**, TOS відповідає на **«як це працює щодня?»**

## 19.1. Governance

- конституція;
- форум;
- пропозиції;
- голосування;
- A/B-тести;
- бюджет;
- картки проєктів;
- кошториси;
- звіти;
- ролі;
- арбітраж;
- історія рішень;
- локальні правила;
- федеративна координація.

## 19.2. Інші модулі

- фінанси;
- виробництво;
- сільське господарство;
- вода;
- енергетика;
- медицина;
- освіта;
- склади;
- житло;
- транспорт;
- екстрене реагування;
- пам’ять громади;
- бібліотека знань;
- AI-асистенти;
- **ресурсний дашборд** (додано у v0.3) — відкритий, спільний аналітичний інструмент, що показує наявні ресурси, потреби й сезонність; надає рекомендації та швидко прораховує варіанти, але не ухвалює рішень — фінальний вибір завжди лишається за людьми.

## 19.3. Resource Graph, Simulation Runtime і compute

TOS розглядається як **нейтральний operational runtime**, а не як ідеологічний орган Vilnism. Один і той самий TOS може використовувати людина, компанія, дослідницька команда або громада з іншою системою цінностей.

У Civilization OS TOS може пов'язувати:

- локальні CPU/GPU/RAM/storage/network ресурси;
- сервери, ноутбуки, робочі станції, VPS і settlement nodes;
- фізичні ресурси — вода, енергія, запаси, обладнання, транспорт та інфраструктура;
- tasks, agents, experiments і simulation jobs;
- `CivilizationGraph` dependencies із реальним `ResourceGraph` state;
- evidence, provenance, confidence, freshness та simulation snapshots.

Simulation Engine повинен мати щонайменше чотири режими поверх спільної моделі:

1. **Interactive Game** — візуальна відеогра та multiplayer;
2. **Headless Research** — тисячі/мільйони симуляцій без графічного рендеру;
3. **Governance Sandbox** — безпечне моделювання наслідків пропозицій без автоматичного права виконання;
4. **Reality Digital Twin** — read-only snapshot реального поселення або організації.

Обчислення можуть виконуватися на власному вузлі, у добровільно об'єднаному Private Grid або, після окремої реалізації та перевірки sandbox/security, у Global Compute Exchange. Локальне інтерактивне навантаження власника завжди має пріоритет над зовнішнім spot compute.

## 19.4. Межа між симуляцією та рішенням

Simulation result є доказовим артефактом, а не законом. TOS повинен зберігати різницю між `observed`, `reported`, `derived`, `estimated`, `forecast`, `simulated` і `assumed` станами.

Правило:

> **Reality constrains the model. Simulation explores futures. Humans authorize consequential choices.**

Жодна governance simulation, AI forecast або результат мільйона прогонів не створює автоматичного права змінити реальні ресурси, права людей чи policy.

## 19.5. Архітектурні вимоги

- модульність;
- API-first;
- локальна робота;
- синхронізація після відновлення зв’язку;
- відкритий код;
- контроль даних користувачем;
- журнал змін;
- криптографічна перевірка;
- відсутність єдиної критичної точки;
- можливість працювати без блокчейну;
- блокчейн лише там, де він дає реальну користь.

-----

-----

# 20. AI як інтерфейс до знань

AI може пояснювати статті, показувати історію змін, порівнювати форки, знаходити суперечності, перекладати складну мову, допомагати формувати пропозиції, будувати сценарії й навчати.

AI не повинен:

- бути остаточним моральним авторитетом;
- таємно формувати правила;
- замінювати голосування;
- приховувати джерела;
- видавати невизначеність за факт;
- набувати статусу «бога» в управлінському сенсі.

Як художній персонаж він може мати міфологічну форму. Як реальна система він має бути підзвітним інструментом.

## 20.1. Федеративна, а не централізована архітектура (додано у v0.3) {#s20-001}

У міру масштабування мережі комун (§25) один центральний AI на всю мережу створив би саме ту точку концентрації впливу, від якої захищається §15. Натомість:

- Кожна група має локальний, підзвітний інстанс, натренований на власних, видимих спільноті даних, а не єдиний загальний навчальний корпус для всієї мережі.
- Жодна пропозиція AI не досягає людини без видимого журналу того, чому вона зроблена саме така: дані, логіка, розглянуті й відкинуті альтернативи — за аналогією з Git-історією канону (§17), але для AI-логіки.

-----

-----

# 21. Культурний шар і Light Illusions

*Light Illusions* може бути художнім всесвітом, що досліджує свободу, контроль, пам’ять, технологічну залежність, міські й автономні моделі життя, межі людського, страх і вибір між комфортом та свободою.

Вільнізм вплітається тонко — через рішення героїв, наслідки, образи й питання.

Серіал не видає художню міфологію за емпіричну істину. Його роль — культурний вхід, який може вести до сайту, канону, AI-персонажа, форуму, TOS, краудфандингу і реальних пілотів.

-----

-----

# 22. Відкрита критика

Вільнізм будує механізми, які роблять критику продуктивною.

Критик має право запитати:

- Чи прихована тут централізація влади?
- Хто контролює гроші?
- Чи можна реально вийти?
- Чи не стане AI новим авторитетом?
- Чи не перетвориться громада на культ?
- Хто захищає дітей і меншини?
- Як вирішуються злочини?
- Чи не створює багатий учасник неформальну владу?
- Чи не стає канон догмою?
- Чи працює система без харизматичного засновника?
- Чи можна повторити модель без великого капіталу?
- Які дані підтверджують ефективність?
- Хто визначає, що таке «краще життя»?

Відповідь не може бути «довіряйте нам». Вона має виглядати так: ось правило, код, історія, бюджет, дані, обмеження, невизначеність, право на форк і право на вихід.

-----

-----

# 23. Що НЕ є Vilnism

Вільнізм не є:

- завершеною істиною;
- релігією;
- культом засновника;
- політичною партією;
- таємною організацією;
- програмою насильницького захоплення влади;
- сепаратистською доктриною;
- приватною армією;
- схемою уникнення законів;
- системою тотального контролю;
- обов’язковою комуною для всіх;
- вимогою відмовитися від міст;
- забороною приватної власності;
- вимогою матеріальної однаковості;
- обіцянкою життя без праці;
- гарантією від конфліктів;
- вірою в те, що технологія автоматично вирішить соціальні проблеми;
- доказом художніх або езотеричних концепцій;
- заміною науки міфологією.

-----

-----

# 24. Основні ризики і запобіжники

## Культ засновника {#s24-001}

Захист: розподілене авторство, форки, ротація ролей, відсутність довічних посад, публічна критика.

## Прихована влада грошей {#s24-002}

Захист: внески не купують голоси, відкриті бюджети, конфлікти інтересів, відсутність одноосібного контролю скарбниці.

## Бюрократизація {#s24-003}

Захист: автоматичне припинення застарілих правил, регулярне видалення процедур, автоматизація, оцінка вартості кожного процесу.

## Тиранія більшості {#s24-004}

Захист: непорушні права, апеляція, право на вихід, захист меншості, високий поріг для зміни ядра.

## Технологічний контроль {#s24-005}

Захист: локальні копії, відкритий код, мінімізація даних, необов’язковість цифрового профілю, офлайн-режим, незалежна перевірка.

## Ідеологічна замкненість {#s24-006}

Захист: зовнішні дослідники, негативні результати, порівняння альтернатив, підтримка форків, відсутність монополії на інтерпретацію.

## Захоплення влади через перехід між кризовими режимами (додано у v0.2) {#s24-007}

Захист: наперед визначені, вимірювані й незалежно перевірювані тригери переходу; автоматичне повернення до попереднього режиму без потреби голосування (§12.3).

## Накопичення неформального впливу за формально рівних прав (додано у v0.2) {#s24-008}

Захист: жереб для координаційних ролей, термінові ліміти, анонімізація пропозицій, розділені технічні повноваження, множинні незалежні методики порівняння комун (§15).

## Ескалація конфлікту через непередбачуваність або особисту вигоду координатора (додано у v0.3) {#s24-009}

Захист: заздалегідь узгоджені й публічно відомі критерії вступу в конфлікт і відступу, засекречена лише міра сили, а не сама доктрина рішень; заборона на преференційний доступ координатора до вигод від конфлікту (§13).

## Застій влади через подовжене чи змінене людське життя (додано у v0.3) {#s24-010}

Захист: обмеження влади за кумулятивним обсягом рішень, а не лише за часом; примусова періодична ін’єкція нових перспектив у процес ухвалення рішень незалежно від тривалості перебування особи на посаді (§15.5).

-----

-----

# 25. Відкрита дорожня карта

Дорожня карта публічна, версіонована і змінюється на основі результатів.

## Етап 0. Формування ядра {#s25-001}

- перша версія Foundations of Vilnism;
- карта принципів і відкритих питань;
- репозиторій;
- правила внесків;
- стандарти версіонування.

## Етап 1. Canon Studio {#s25-002}

- редактор;
- Git-історія;
- SHA-перевірка;
- переклади;
- форки;
- вебверсія.

## Етап 2. Спільнота і форум {#s25-003}

- обговорення кожної статті;
- пропозиції;
- експертні групи;
- модерація;
- карта аргументів;
- архів рішень.

## Етап 3. TOS Governance MVP {#s25-004}

- конституція;
- форум;
- голосування;
- бюджетні проєкти;
- відкриті кошториси;
- журнал рішень.

## Етап 4. Пілоти в існуючих спільнотах {#s25-005}

Тестування в кооперативах, екопоселеннях, освітніх і виробничих командах, громадських організаціях та житлових проєктах.

## Етап 5. Перша фізична громада {#s25-006}

- земля;
- правова оболонка;
- житло;
- вода;
- енергія;
- їжа;
- майстерні;
- локальна мережа;
- освіта;
- прозорий бюджет;
- зовнішній економічний шлюз.

## Етап 6. Мережа громад {#s25-007}

- незалежні форки;
- федеративна координація;
- обмін знаннями;
- взаємна допомога;
- спільні стандарти;
- локальна автономія.

## Етап 7. Масштабування до 100 000 учасників {#s25-008}

Масштабування відбувається через мережу вузлів, а не один мегапроєкт. Основні метрики: якість життя, добровільність, стійкість, фінансова життєздатність, кількість незалежних команд і здатність пережити втрату центрального вузла.

## Етап 8. Міста нового типу {#s25-009}

Місто будується як федерація людських за масштабом секторів, а не як одна централізована маса.

## Етап 9. Глобальна відкрита цивілізаційна мережа {#s25-010}

Не єдина світова держава, а мережа громад, міст, кооперативів, дослідницьких центрів, цифрових платформ і культурних проєктів, що використовують сумісні відкриті стандарти, зберігають локальну свободу й реалізують спільні наукові та інфраструктурні проєкти.

-----

-----

# 26. Культурне поширення і маркетинг

Можлива воронка:

1. короткі відео та історії;
1. *Light Illusions* як емоційний вхід;
1. сайт;
1. AI-персонаж;
1. відкритий канон;
1. форум;
1. Canon Studio;
1. TOS;
1. краудфандинг конкретного продукту;
1. пілотні спільноти;
1. фізичні громади;
1. туризм, стажування і тимчасове проживання;
1. незалежні форки.

Краудфандинг фінансує не «утопію», а конкретний перевірний результат: відкритий стандарт, Canon Studio, Governance MVP, освітній набір, архітектурний прототип, пілотний будинок, водну або енергетичну систему чи перший дослідний центр.

-----

-----

# 27. Підсумкова формула

> **Жити вільно.
> Бути здоровим.
> Мислити критично.
> Любити й співпрацювати.
> Творити й навчатися.
> Не поневолювати інших.
> Використовувати технології для звільнення часу.
> Будувати стійкі спільноти.
> Зберігати знання.
> Передавати світ далі кращим, ніж ми його отримали.**

-----

-----

# 29. Модель загроз, деградація та відновлення системи

## 29.1. Вихідний принцип {#s28-001}

Жодна суспільна система не є незламною.

Навіть система, побудована на добровільності, відкритому коді, прозорих бюджетах, праві на вихід, ротації ролей і федеративній архітектурі, може поступово втратити свої початкові властивості.

Вона може бути зламана:

- навмисною внутрішньою або зовнішньою атакою;
- накопиченням неформального впливу;
- технологічною залежністю;
- економічною кризою;
- демографічним зсувом;
- інформаційною маніпуляцією;
- помилковими метриками;
- виснаженням учасників;
- надмірною складністю;
- серією добросовісних, але невдалих рішень;
- одночасним поєднанням кількох слабких криз.

Тому метою Вільнізму не є створення системи, яку неможливо зламати.

> **Метою є створення системи, яка здатна рано виявити власне погіршення, обмежити поширення збою, зберегти базові права, перейти до простішого режиму, відновитися або мирно розділитися без незворотного захоплення влади.**

Модель загроз застосовується не лише до зовнішніх ворогів. Вона насамперед застосовується до самої системи, її засновників, координаторів, технічних спеціалістів, економічних партнерів, AI-інструментів і культури спільноти.

## 29.2. Що саме необхідно захищати {#s28-002}

Безпека Вільнізму не зводиться до захисту серверів, грошей або фізичної території.

### 29.2.1. Людська автономія {#s28-003}

- фізична недоторканність;
- свобода думки й висловлювання;
- право не погоджуватися;
- право не брати активної участі в політиці;
- право на приватність;
- право на добровільну згоду;
- реальне право на вихід;
- право не ставати ресурсом системи.

### 29.2.2. Базові умови життя {#s28-004}

- вода;
- їжа;
- житло;
- енергія;
- медицина;
- санітарія;
- зв’язок;
- доступ до критичних знань;
- фізична безпека;
- здатність підтримувати життя в локальному, офлайн- та аварійному режимах.

### 29.2.3. Інституційна цілісність {#s28-005}

- неможливість одноосібно змінити канон;
- перевірювана історія рішень;
- підзвітність влади;
- обмеженість кризових повноважень;
- незалежність апеляції;
- розділення технічних і політичних повноважень;
- можливість відкату правил;
- можливість створення форку.

### 29.2.4. Епістемічна цілісність {#s28-006}

Епістемічна цілісність означає здатність спільноти відрізняти:

- факт від припущення;
- дані від інтерпретації;
- помилку від саботажу;
- аргумент від статусу автора;
- науковий висновок від політичної рекомендації;
- реальне покращення від маніпуляції метрикою;
- невизначеність від прихованого незнання.

### 29.2.5. Технологічна незалежність {#s28-007}

- можливість перевірити критичний код;
- можливість відтворити інфраструктуру;
- відсутність незамінних операторів;
- локальні копії знань і даних;
- робота без глобального інтернету;
- ручні резервні процедури;
- контроль людини над власними даними;
- відсутність єдиного критичного AI, сервера, ключа чи провайдера.

### 29.2.6. Соціальна довіра {#s28-008}

Довіра не означає сліпу віру в людей або інституції. У стійкій системі вона виникає через можливість перевірки, передбачуваність процедур, публічне визнання помилок, однакове застосування правил, захист меншості та відсутність прихованих винятків.

## 29.3. Суб’єкти загроз {#s28-009}

Загроза може виникати не лише від злочинця чи зовнішнього ворога. Її джерелом може бути добросовісна людина, від компетенції якої система стала надмірно залежною.

### 29.3.1. Харизматичний засновник або моральний авторитет {#s28-010}

Така людина може не мати формальної посади, але фактично визначати допустимі межі критики, «правильне» тлумачення канону, культурний тон, доступ до донорів і репутацію інших учасників.

### 29.3.2. Організована внутрішня фракція {#s28-011}

Невелика дисциплінована група може отримати непропорційний вплив через постійну присутність у дискусіях, координацію голосувань, контроль порядку денного та взаємну підтримку кандидатів.

### 29.3.3. Технічна каста {#s28-012}

Інженери, адміністратори, оператори TOS, розробники AI та власники ключів можуть стати фактично незамінними навіть без юридичної влади.

### 29.3.4. Економічно домінуючий учасник {#s28-013}

Людина, компанія чи група, яка забезпечує значну частину доходу, володіє критичною землею, контролює транспорт, обладнання або зовнішні зв’язки, може отримати фактичне право вето без формальної купівлі голосів.

### 29.3.5. Зовнішня держава, компанія або організація {#s28-014}

Зовнішня структура може впливати через юридичний тиск, землю, податки, ліцензування, фінансові обмеження, контроль поставок, інформаційні операції, підкуп або створення ресурсної залежності.

### 29.3.6. AI-система з прихованим або систематичним зсувом {#s28-015}

AI може впливати не через формальне рішення, а через формулювання проблеми, відбір альтернатив, порядок представлення аргументів, скорочення міноритарних позицій та визначення того, що вважається нормальним.

### 29.3.7. Добросовісна, але некомпетентна більшість {#s28-016}

Більшість може підтримати небезпечне рішення через страх, втому, групову поляризацію, недостатню інформацію або нерозуміння технічних наслідків.

### 29.3.8. Неформальні соціальні мережі {#s28-017}

Родинні, романтичні, дружні, професійні або фінансові зв’язки можуть утворити центри влади, яких не видно у формальній структурі.

### 29.3.9. Культурна більшість {#s28-018}

Навіть без юридичного примусу більшість може створити середовище, у якому критика формально дозволена, але соціально карається, вихід вважається зрадою, а приватність — підозрілістю.

## 29.4. Класи системних загроз {#s28-019}

### 29.4.1. Захоплення формальної влади {#s28-020}

Відбувається, коли одна особа або група отримує контроль над голосуванням, модерацією, бюджетом, призначеннями, кризовими повноваженнями, апеляціями або змінами канону.

### 29.4.2. Захоплення неформальної влади {#s28-021}

Формальні процедури залишаються незмінними, але реальні рішення залежать від засновника, експертної касти, донора, групи старожилів, культурного авторитету або технічного оператора.

### 29.4.3. Захоплення порядку денного {#s28-022}

Система може мати чесне голосування, але нечесний набір варіантів. Ознаки:

- одні проблеми постійно не виносяться на обговорення;
- альтернативи формулює одна група;
- нульовий варіант не розглядається;
- міноритарна пропозиція подається у слабшій формі;
- складне питання штучно зводиться до двох варіантів;
- рішення без достатніх підстав оголошується терміновим.

### 29.4.4. Захоплення інтерпретації {#s28-023}

Текст канону може залишатися незмінним, але одна група поступово отримує монополію на пояснення того, що він «насправді означає».

Фрази на кшталт «дух Вільнізму вимагає», «засновник мав на увазі» або «справжній учасник не став би так запитувати» мають розглядатися як сигнали можливого захоплення інтерпретації.

### 29.4.5. Захоплення технічної інфраструктури {#s28-024}

Відбувається через контроль серверів, ключів, журналів, резервних копій, AI-моделей, алгоритмів підрахунку, каналів зв’язку або процесу розгортання оновлень.

### 29.4.6. Економічне захоплення {#s28-025}

Система стає залежною від одного донора, клієнта, банку, токена, постачальника, власника землі, експортного продукту або джерела енергії.

### 29.4.7. Інформаційне захоплення {#s28-026}

Відбувається, коли одна сторона здатна визначати, що люди бачать, яким джерелам довіряють, які події потрапляють до офіційної історії та хто має право публікувати кризові повідомлення.

### 29.4.8. Метрикократія {#s28-027}

Показники, створені для оцінки системи, починають керувати системою. Рішення приймаються для покращення цифр, а не життя людей.

### 29.4.9. Бюрократичне захоплення {#s28-028}

Процедури, створені для захисту, самі стають бар’єром. Правила множаться швидше, ніж видаляються; люди не розуміють власних прав без посередника; governance споживає непропорційно багато часу.

### 29.4.10. Кризове захоплення {#s28-029}

Надзвичайна ситуація використовується для централізації, скасування приватності, обмеження виходу, призупинення критики або подовження тимчасових повноважень.

## 29.5. Загрози без навмисного атакувальника {#s28-030}

### 29.5.1. Втрата ключових людей {#s28-031}

Причинами можуть бути смерть, хвороба, конфлікт, виїзд, вигорання, зовнішній арешт або одночасна відсутність кількох спеціалістів.

Кожна критична функція повинна пройти тест:

> **Чи може система працювати, якщо одночасно зникають п’ять найбільш компетентних у цій сфері людей?**

### 29.5.2. Виснаження активної меншості {#s28-032}

Якщо управління, аудит, допомога, модерація й кризове реагування тримаються на тих самих людях, вони вигорають, стають цинічними, втрачають терпіння до критики або залишають систему.

### 29.5.3. Демографічна деградація {#s28-033}

- старіння населення;
- недостатня народжуваність;
- відтік молоді;
- нестача певних професій;
- дисбаланс між працездатними й залежними учасниками;
- конфлікт поколінь;
- відмова другого покоління підтримувати систему.

### 29.5.4. Побутова деградація {#s28-034}

Суспільства часто руйнуються не через великі теорії, а через несправедливий розподіл побутової праці, шум, догляд за дітьми, романтичні конфлікти, залежності, борги, санітарні проблеми, особисті образи та нерівний доступ до житла.

### 29.5.5. Дефіцит ресурсів {#s28-035}

Особливо небезпечними є тривалі перебої води, їжі, енергії, ліків, житла, транспорту, зовнішньої валюти та запчастин.

### 29.5.6. Зниження якості знань {#s28-036}

Знання можуть формально зберігатися, але фактично втрачатися через застарілу документацію, відсутність практики, залежність від AI, дефіцит наставників або розрив між описаною та реальною системою.

### 29.5.7. Перевантаження складністю {#s28-037}

Навіть правильна архітектура стає непрацездатною, якщо її неможливо зрозуміти, підтримувати й відтворювати.

## 29.6. Принципи захисту {#s28-038}

### 29.6.1. Захист не повинен створювати сильнішу загрозу {#s28-039}

Не можна боротися з можливим захопленням через тотальний нагляд, таємну поліцію, презумпцію вини, заборону анонімності, повне розкриття приватного життя або колективну відповідальність.

### 29.6.2. Аналізуються владні дії, а не особистість {#s28-040}

Система може досліджувати концентрацію підписів, повторюваність ролей, контроль бюджетів, залежність інфраструктури та структуру публічних коаліцій. Вона не повинна без необхідності аналізувати приватні стосунки, особисте листування, світогляд або психологічний профіль.

### 29.6.3. Кожна критична функція повинна мати резерв {#s28-041}

Резерв може бути людським, технічним, процедурним, фізичним, територіальним або економічним.

### 29.6.4. Жоден захисний механізм не є достатнім сам по собі {#s28-042}

Відкритий код не замінює аудит. Жереб не замінює компетентність. Голосування не замінює права меншості. Право на вихід не замінює матеріальну можливість вийти. Прозорість не замінює приватність. AI-пояснення не замінює людське розуміння.

## 29.7. Система раннього виявлення деградації {#s28-043}

Деградація зазвичай починається не з відкритої диктатури, а з невеликих відхилень, кожне з яких окремо здається виправданим.

### 29.7.1. Індикатори концентрації впливу {#s28-044}

- частка рішень, підготовлених однією групою;
- частота повторної участі тих самих людей у координаційних ролях;
- кількість критичних функцій, залежних від однієї особи;
- частка бюджету, яку фактично контролює одна команда;
- концентрація зовнішніх доходів;
- кількість незалежних технічних інстансів;
- кількість людей, здатних відновити критичну систему;
- частка пропозицій від нових учасників;
- частота рішень, ухвалених усупереч позиції найбільш авторитетної групи.

### 29.7.2. Індикатори зниження реальної свободи {#s28-045}

- збільшення вартості або строку виходу;
- зменшення переносимості даних і активів;
- соціальні санкції проти критиків;
- збільшення обов’язкових процедур;
- частіше використання кризових винятків;
- зростання кількості «термінових» рішень;
- зменшення реальної кількості альтернатив.

### 29.7.3. Індикатори соціальної деградації {#s28-046}

- зниження довіри;
- зростання внутрішніх конфліктів;
- збільшення плинності учасників;
- масовий вихід молоді;
- зростання нерівності доступу до житла й ресурсів;
- концентрація неоплачуваної праці в одній групі;
- зростання вигорання;
- зменшення добровільної участі.

### 29.7.4. Індикатори технологічної деградації {#s28-047}

- зменшення кількості людей, здатних зрозуміти критичний код;
- відсутність успішних навчань із відновлення;
- залежність від одного провайдера;
- неперевірені оновлення;
- закриті компоненти у критичній інфраструктурі;
- збільшення обсягу даних про кожного учасника;
- неможливість роботи без AI;
- відсутність ручної альтернативи;
- невідповідність документації реальному стану.

### 29.7.5. Індикатори маніпуляції метриками {#s28-048}

- показники покращуються, а кількість виходів зростає;
- середнє покращується, але найгірші 10% погіршуються;
- різке покращення після зміни методики;
- неврахована праця зростає;
- негативні результати рідше публікуються;
- учасники бояться давати негативні відповіді;
- незалежні інтерв’ю суперечать офіційним цифрам.

## 29.8. Рівні стану системи {#s28-049}

Стан визначається не одним показником, а сукупністю незалежних ознак. Різні підсистеми можуть мати різний рівень одночасно.

### 29.8.1. Зелений рівень — нормальна працездатність {#s28-050}

Ознаки: базові права реально працюють, критичні функції дубльовані, бюджет і рішення перевірювані, вихід доступний, критика не карається.

Дії: звичайний моніторинг, планові навчання, регулярне спрощення правил, публікація звітів.

### 29.8.2. Жовтий рівень — рання концентрація або залежність {#s28-051}

Ознаки: одна людина чи команда стає важкозамінною, зростає залежність від одного джерела доходу, повторюються ті самі координатори, збільшується складність.

Дії: обов’язковий аудит, план зменшення залежності, дублювання компетенцій, додаткова ротація, перевірка реальної вихідності.

### 29.8.3. Помаранчевий рівень — функціональна деградація {#s28-052}

Ознаки: контрольні механізми формально існують, але працюють слабко; одна група визначає порядок денний; критична система не має резерву; кризові винятки використовуються регулярно.

Дії: замороження некритичних змін, незалежна перевірка, обмеження великих витрат, розділення ключових повноважень, запуск альтернативного вузла, перегляд метрик, підготовка часткового форку.

### 29.8.4. Червоний рівень — фактична втрата гарантій {#s28-053}

Ознаки: право на вихід стало формальним; критики переслідуються; дані використовуються для політичного тиску; одна сторона контролює бюджет, інфраструктуру й інформацію; апеляція залежить від тієї самої групи.

Дії: автоматичне звуження централізованих повноважень, відключення некритичних систем спостереження, незалежна апеляція, передача копій даних і канону зовнішнім довіреним вузлам, активація фонду виходу, підготовка мирного розділення.

### 29.8.5. Чорний рівень — втрата сумісності з Вільнізмом {#s28-054}

Ознаки: людина фактично є власністю системи; вихід заборонений або карається; критика переслідується; історія рішень переписується; одна група має незворотний контроль; базові права залежать від політичної лояльності.

На чорному рівні система не може називатися сумісною реалізацією Вільнізму, навіть якщо зберігає назву, символіку чи програмне забезпечення.

## 29.9. Правила переходу між рівнями {#s28-055}

- рівень не визначається одноосібно;
- потрібні незалежні канали підтвердження;
- різні рівні можуть діяти для різних підсистем;
- повернення на нижчий рівень потребує усунення причини, незалежної перевірки, повторного тесту та періоду стабільної роботи;
- AI може готувати оцінку, але не встановлює рівень самостійно.

## 29.10. Протоколи контрольованої деградації {#s28-056}

Контрольована деградація означає, що при втраті частини можливостей система не руйнується повністю, а переходить до простішої форми.

### 29.10.1. Технологічна деградація {#s28-057}

1. повна цифрова система;
2. локальна мережа;
3. окремі автономні вузли;
4. офлайн-копії;
5. паперові журнали;
6. усні й фізичні аварійні протоколи.

### 29.10.2. Управлінська деградація {#s28-058}

При втраті складного governance система переходить до локальних малих груп, мінімального набору правил, замороження некритичних змін, коротких мандатів і рішень, обмежених життєзабезпеченням.

### 29.10.3. Економічна деградація {#s28-059}

Базовий порядок пріоритетів: вода, санітарія, їжа, житло, медицина, енергія критичних систем, зв’язок, транспорт, освіта, інші функції. Відхилення потребує явного обґрунтування.

### 29.10.4. Інформаційна деградація {#s28-060}

Якщо цифровій інформації не можна довіряти, критичні рішення не базуються на одному джерелі, документи перевіряються підписами й хешами, а незворотні дії не запускаються сенсаційною інформацією без підтвердження.

### 29.10.5. Соціальна деградація {#s28-061}

Якщо довіра різко падає, зменшується кількість великих колективних рішень, повноваження переносяться до менших груп, а пріоритет отримують безпека, медіація та базове функціонування.

## 29.11. Протокол відновлення після великої помилки {#s28-062}

Обов’язкові етапи:

1. захист життя й стабілізація;
2. збереження доказів;
3. тимчасове розділення повноважень;
4. незалежне розслідування;
5. право всіх сторін бути почутими;
6. розділення людської помилки, недбалості, системного дефекту та саботажу;
7. компенсація постраждалим;
8. виправлення системи;
9. публічний звіт;
10. перевірка виконання рекомендацій;
11. захист від перетворення трагедії на постійне виправдання централізації.

## 29.12. Протокол мирного розділення {#s28-063}

Єдність не є вищою цінністю за свободу й безпеку. Якщо стратегічна незгода стала стійкою, допускається структуроване розділення.

Протокол визначає:

- хто має право ініціювати розділення;
- мінімальний період медіації;
- інвентаризацію активів і боргів;
- доступ до води, енергії й доріг;
- права дітей і залежних осіб;
- переносимість даних;
- право на копію канону й ПЗ;
- правила використання назви;
- можливість майбутнього об’єднання;
- заборону колективного покарання групи, що відокремлюється.

## 29.13. Протокол повторного об’єднання {#s28-064}

Можливі форми: сумісні стандарти, спільна інфраструктура, взаємне визнання прав, часткове об’єднання модулів, спільні наукові проєкти, федеративна угода або повне об’єднання після випробувального періоду.

## 29.14. Red Team — систематичне випробування системи {#s28-065}

Спільнота повинна мати незалежну функцію, завдання якої — шукати способи зламати систему.

Red Team перевіряє:

- захоплення порядку денного;
- маніпуляцію голосуванням;
- приховану зміну коду;
- підроблення метрик;
- блокування виходу;
- залежність від одного адміністратора;
- використання кризи для постійної влади;
- систематичний зсув AI;
- фактичне право вето донора;
- захоплення пасивної більшості організованою меншістю.

Red Team не має постійної влади, регулярно змінюється, не контролюється тими, кого перевіряє, і не використовується для політичного переслідування.

## 29.15. Обов’язкові стрес-тести {#s28-066}

Кожна комуна регулярно моделює:

1. зникнення ключової технічної команди;
2. втрату головного джерела доходу;
3. тиждень без інтернету;
4. тривалий дефіцит води;
5. масовий вихід 20% учасників;
6. розкол 50/50;
7. компрометацію TOS;
8. помилкову рекомендацію AI;
9. ворожу інформаційну кампанію;
10. конфлікт щодо прав дитини;
11. відмову активної меншості продовжувати неоплачувану роботу;
12. смерть або відхід засновника;
13. юридичне блокування інфраструктури;
14. одночасну економічну, технічну й соціальну кризу;
15. виявлення прихованої коаліції в управлінні.

## 29.16. Бюджет складності {#s28-067}

Кожна нова процедура має вартість: час, технічну підтримку, юридичну складність, навчання, ризик помилки, залежність від спеціалістів, психологічне навантаження та обсяг даних.

Кожне правило повинно мати:

- конкретну проблему, яку воно вирішує;
- спрощене пояснення;
- власника відповідальності;
- дату перегляду;
- критерій успіху;
- критерій автоматичного припинення;
- процедуру відкату.

## 29.17. Мінімальний незмінний набір під час будь-якої кризи {#s28-068}

Навіть у найважчому режимі не можуть автоматично скасовуватися:

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

## 29.18. Ознаки втрати сумісності з Вільнізмом {#s28-069}

Громада, форк або цифрова система втрачає сумісність із базовим ядром, якщо:

- вихід фактично неможливий;
- базові ресурси використовуються для політичного примусу;
- людина оголошується власністю спільноти;
- критика карається;
- влада не може бути відкликана;
- історія рішень приховується або переписується;
- AI отримує остаточний авторитет;
- приватні дані стають умовою політичної лояльності;
- внесок купує владу;
- діти ізолюються від альтернативної інформації;
- надзвичайний режим не має автоматичного завершення;
- форк блокується силою, боргом або утриманням даних.

## 29.19. Підсумковий принцип {#s28-070}

> **Стійка система — не та, що ніколи не помиляється, а та, що не приховує помилку, не дозволяє їй захопити все суспільство, зберігає права людини під час деградації та має перевірний шлях до відновлення, відкату або мирного розділення.**

-----

-----

# 30. Протоколи важких випадків і конфлікту принципів

## 30.1. Навіщо потрібен окремий розділ {#s29-001}

Більшість систем руйнується не там, де принцип очевидний, а там, де два правильні принципи вступають у конфлікт.

Приклади:

- свобода людини проти обов’язку не завдавати шкоди;
- приватність проти безпеки;
- право на вихід проти невиконаних зобов’язань;
- автономія батьків проти прав дитини;
- рівність політичного впливу проти нерівності компетенцій;
- локальна автономія проти загальних медичних або технічних стандартів;
- прозорість проти необхідної секретності;
- автоматизація проти збереження резервних навичок;
- право на форк проти збереження спільної інфраструктури.

Жоден принцип не повинен автоматично перемагати в усіх ситуаціях лише через красиве формулювання.

## 30.2. Матриця конфлікту принципів {#s29-002}

Кожне складне рішення повинно явно відповідати на п’ять питань:

1. Які права й принципи вступили в конфлікт?
2. Яка шкода виникає при кожному варіанті?
3. Які наслідки є оборотними, а які — ні?
4. Хто несе найбільший ризик, але має найменше впливу?
5. Яке рішення залишає найбільше можливостей для подальшого виправлення?

За інших рівних умов перевагу має рішення, що:

- завдає меншої незворотної шкоди;
- зберігає можливість апеляції;
- не створює постійної концентрації влади;
- не перекладає основний ризик на меншину;
- може бути перевірене локальним пілотом;
- має чіткий строк перегляду.

## 30.3. Людина, яка не робить внеску {#s29-003}

Базові права, політичні права та людська гідність не залежать від продуктивності.

Водночас система не повинна приховувати проблему систематичного користування спільними ресурсами без взаємності, якщо людина здатна робити внесок.

Можливі форми внеску включають:

- фізичну працю;
- догляд;
- навчання;
- творчість;
- кризове чергування;
- технічну або інтелектуальну роботу;
- наставництво;
- зовнішній дохід;
- участь у непопулярних, але необхідних задачах.

Реакція на тривалу відсутність внеску проходить послідовно:

1. перевірка здоров’я, інвалідності, вигорання та прихованої праці;
2. розмова без публічного осуду;
3. пропозиція різних форм участі;
4. добровільний план внеску;
5. медіація;
6. перегляд доступу лише до додаткових, небазових привілеїв або проєктів;
7. можливість переходу до іншої форми членства;
8. право на вихід із гарантією базової гідності.

Позбавлення води, їжі, невідкладної медицини, свободи або політичних прав не може бути покаранням за низьку продуктивність.

## 30.4. Реальне право на вихід {#s29-004}

Формально відчинені двері не означають реальної свободи.

Система повинна вимірювати фактичну вихідність:

- строк процедури;
- обсяг ресурсів, який людина може забрати;
- переносимість особистих, медичних і освітніх даних;
- визнання освіти й кваліфікацій поза громадою;
- доступ до тимчасового житла;
- можливість вийти без публічного пояснення;
- відсутність санкцій щодо родичів і друзів;
- можливість перейти до іншого форку;
- спеціальні гарантії для дітей, літніх людей і залежних осіб.

Фонд виходу повинен бути фінансово й адміністративно відокремлений від локальної групи, з якої виходить людина.

## 30.5. Діти та добровільність другого покоління {#s29-005}

Дитина не обирає систему, у якій народжується. Тому добровільність першого покоління не може автоматично переноситися на наступне.

Кожна дитина має право:

- знати про альтернативні системи життя;
- отримувати освіту, що визнається за межами громади;
- мати доступ до зовнішньої інформації;
- мати незалежного захисника своїх прав;
- не ставати об’єктом ідеологічної ізоляції;
- після повноліття вийти з реальним стартовим ресурсом;
- не зазнавати емоційної чи економічної помсти за незгоду.

Автономія батьків не є правом позбавляти дитину майбутнього вибору.

## 30.6. Багатий учасник, великий донор і зовнішній інвестор {#s29-006}

Внесок не купує політичну владу, але економічна залежність може створити її фактично.

Захист:

- гранична частка бюджету від одного джерела;
- обов’язковий план заміни критичного донора;
- заборона ексклюзивного контролю над землею, транспортом або зовнішніми контрактами;
- публічні конфлікти інтересів;
- відокремлення благодійного внеску від права визначати зміст канону;
- резерв на випадок раптового припинення фінансування;
- переносимість ділових відносин між кількома командами.

## 30.7. Компетентність проти рівності {#s29-007}

Жереб і рівність голосу захищають від політичної касти, але не створюють технічної компетентності.

Тому слід розділяти:

- право визначати цінності й допустимий ризик;
- право надавати експертний висновок;
- право виконувати технічну операцію;
- право перевіряти виконання.

Експерт не отримує додаткового політичного голосу, але його твердження не прирівнюються до випадкової думки в питаннях факту. Водночас експертний висновок повинен містити невизначеність, альтернативи, конфлікти інтересів і можливість незалежної перевірки.

## 30.8. Приватність проти безпеки {#s29-008}

Збір даних допускається лише тоді, коли:

- існує конкретна мета;
- немає менш інвазивного способу;
- строк зберігання обмежений;
- доступ розділений;
- людина знає, які дані існують;
- політичні, медичні, фінансові й побутові профілі не об’єднуються автоматично;
- дані не використовуються для оцінки лояльності;
- існує процедура видалення та апеляції.

Навіть у кризі масове спостереження не стає нормою за замовчуванням.

## 30.9. AI як рамкова влада {#s29-009}

AI не лише відповідає на питання — він визначає, які питання та альтернативи люди бачать.

Тому для значних рішень AI повинен:

- показувати джерела;
- відокремлювати факти від оцінок;
- представляти міноритарну позицію;
- шукати пропущені альтернативи;
- показувати аргументи проти власної рекомендації;
- позначати невизначеність;
- вести журнал версії моделі, промптів і даних;
- дозволяти порівняння кількох незалежних моделей;
- мати повністю ручний режим обходу.

Жодна AI-рекомендація не може бути єдиною підставою для незворотної дії щодо людини.

## 30.10. Метрики та права меншості {#s29-010}

Середній показник не є достатнім доказом успіху.

Кожна ключова метрика повинна показувати:

- медіану;
- найгірші 10%;
- розподіл між групами;
- кількість і причини виходів;
- неоплачувану та приховану працю;
- незалежні якісні інтерв’ю;
- зміни методики;
- можливі способи маніпуляції.

Система не може вважатися успішною, якщо середнє покращується за рахунок систематичного погіршення становища меншості.

## 30.11. Право не займатися governance {#s29-011}

Свобода включає право не читати кожну пропозицію, не голосувати постійно й не перетворювати життя на нескінченне адміністрування.

Governance має бути:

- мінімальним;
- делегованим;
- локальним;
- оборотним;
- зрозумілим;
- асинхронним, де це можливо;
- таким, що не карає пасивність втратою базових прав.

Низька участь може бути не лише байдужістю, а сигналом надмірної складності або недовіри.

## 30.12. Непопулярна меншість {#s29-012}

Права людини не залежать від популярності її поглядів, якщо вона не завдає конкретної шкоди іншим.

Захист меншості включає:

- право на власні асоціації;
- право на окрему культурну практику;
- право подавати пропозиції;
- незалежну апеляцію;
- заборону колективного покарання;
- право не брати участі у символічних ритуалах;
- право на частковий або повний форк.

## 30.13. Злочин, небезпечна поведінка та примус {#s29-013}

Вільнізм не може повністю відмовитися від примусових механізмів, якщо існує безпосередня загроза життю або свободі інших.

Будь-який примус повинен бути:

- мінімально необхідним;
- обмеженим у часі;
- документованим;
- пропорційним;
- доступним для апеляції;
- відокремленим від особистої помсти;
- орієнтованим спочатку на припинення шкоди, а не на покарання.

Тимчасова ізоляція небезпечної людини не означає втрату її людської гідності, права на медицину, юридичний захист і перегляд рішення.

## 30.14. Конфлікт між локальною автономією та спільними стандартами {#s29-014}

Комуни можуть експериментувати, але не повинні називати експериментом приховане порушення базових прав.

Спільне ядро встановлює мінімальні стандарти:

- безпеки води й їжі;
- захисту дітей;
- інформованої медичної згоди;
- права на вихід;
- прозорості примусу;
- переносимості даних;
- незалежної апеляції.

Все, що вище цього мінімуму, може бути предметом локальних форків і пілотів.

## 30.15. Ворожий або авторитарний форк {#s29-015}

Відкритість дозволяє копіювати тексти й код, але не зобов’язує визнавати будь-який форк сумісним із Вільнізмом.

Сумісність визначається перевірюваними умовами, а не назвою:

- реальне право на вихід;
- свобода критики;
- заборона власності на людину;
- відсутність довічної влади;
- підзвітність примусу;
- захист дітей;
- контроль людини над даними;
- право на незалежний форк.

## 30.16. Принцип збереження майбутнього вибору {#s29-016}

У складних і невизначених ситуаціях пріоритет має рішення, що не закриває майбутнім людям можливість змінити курс.

Це означає:

- уникати незворотних централізацій;
- не створювати довічних боргів;
- не знищувати альтернативні знання;
- не прив’язувати всі ресурси до одного технічного стандарту;
- не ізолювати дітей від зовнішнього світу;
- не робити форк матеріально неможливим;
- зберігати дані й історію так, щоб наступні покоління могли переоцінити рішення.

> **Найкраще рішення не завжди те, що здається оптимальним сьогодні. Часто це рішення, яке залишає найбільше свободи виправити помилку завтра.**

-----

-----

# 31. Федеративний протокол і поліцентрична цивілізація

## 31.1. Федерація як протокол, а не верхній рівень держави {#s30-001}

Федеративна структура Вільнізму не повинна ставати новою пірамідою влади над комунами. Її базова функція — забезпечувати сумісність автономних вузлів там, де локальної координації недостатньо.

Федерація визначає не те, **як має жити кожна комуна**, а те, **як незалежні комуни можуть безпечно взаємодіяти**.

До федеративного протоколу можуть належати:

- мінімальні базові права;
- переносимість особистих даних і статусів;
- стандарти добровільних міжкомунних угод;
- правила арбітражу;
- формати взаємної допомоги;
- сумісність TOS-вузлів;
- протоколи кризової координації;
- стандарти доказів і журналів рішень;
- правила мирного форку й повторного об’єднання;
- стандарти критичної інфраструктурної сумісності.

> **Делегується координація, а не суверенітет.**

## 31.2. Принцип вичерпно делегованих повноважень {#s30-002}

Федеративна структура не має повноважень за замовчуванням.

Будь-яка федеративна компетенція повинна:

- бути явно делегованою;
- мати конкретну мету;
- мати визначений обсяг;
- мати критерії успіху;
- мати строк або умову автоматичного припинення;
- мати процедуру відкликання;
- бути технічно й процедурно неможливою поза межами мандату там, де це реалізовано безпечно.

Все, що не делеговано, залишається на нижчому рівні.

## 31.3. Принцип найнижчого достатнього рівня {#s30-003}

Питання вирішується на найнижчому рівні, здатному реально його вирішити.

- проблема однієї людини — не питання комуни, якщо не зачіпає інших;
- проблема однієї комуни — не питання федерації;
- спільна річка кількох комун — питання відповідної водної мережі;
- міжрегіональна інфраструктура — питання відповідної функціональної федерації;
- загальноцивілізаційна загроза — тимчасова координація відповідного масштабу.

Вищий рівень не отримує право втручатися лише тому, що він існує.

## 31.4. Функціональні мережі замість єдиної територіальної вертикалі {#s30-004}

Одна й та сама комуна може одночасно входити в різні функціональні мережі:

- водну;
- енергетичну;
- медичну;
- транспортну;
- освітню;
- наукову;
- логістичну;
- арбітражну;
- кризову.

Їхні кордони не зобов’язані збігатися.

Це зменшує ризик, що контроль над однією територією автоматично означатиме контроль над усіма функціями життя.

## 31.5. Багаторівневе представництво без присвоєння голосу {#s30-005}

При великому масштабі пряме глобальне обговорення кожного питання всіма вузлами стає неефективним. Допускається багаторівнева координація:

людина → комуна → кластер → функціональна мережа → федеративний рівень.

Але представник не повинен автоматично ставати власником політичного голосу тих, кого представляє.

Представник може:

- пояснювати контекст;
- вести переговори;
- формувати компроміси;
- передавати мандат;
- повертати нову інформацію на нижчий рівень.

Там, де це можливо, передається не одна бінарна позиція, а реальний розподіл підтримки всередині громади.

> **Представництво передає інформацію й мандат, а не переносить суверенітет особи в руки представника.**

## 31.6. Тимчасові місії замість постійних надструктур {#s30-006}

Для великих завдань можуть створюватися тимчасові структури:

- наукова програма;
- будівництво великої інфраструктури;
- пандемічна відповідь;
- ліквідація катастрофи;
- космічна програма;
- міжрегіональний інфраструктурний перехід.

Кожна така структура має мандат, бюджет, строк, критерій завершення та автоматичний механізм саморозпуску.

## 31.7. Інституційний TTL {#s30-007}

Будь-яке надзвичайне або тимчасове повноваження повинно мати Time To Live.

Після завершення TTL воно автоматично припиняється. Для продовження потрібен новий мандат, а не окреме рішення про скасування.

Це перевертає традиційну бюрократичну логіку:

> **інституція не існує доти, доки її хтось не ліквідує; вона існує лише доти, доки її необхідність регулярно підтверджується.**

## 31.8. Відсутність постійної столиці {#s30-008}

Федерація не повинна мати єдиний незамінний географічний центр.

Можливі:

- ротаційні асамблеї;
- різні міста-господарі;
- розподілені архіви;
- незалежні технічні вузли;
- різні центри науки, арбітражу, логістики й освіти.

Захоплення одного фізичного центру не повинно означати захоплення мережі.

-----

-----

# 32. Захист від ресурсної, технологічної та економічної гегемонії

## 32.1. Проблема незамінності {#s31-001}

Небезпека виникає не тоді, коли певна комуна багата, компетентна або технологічно розвинена. Небезпека виникає тоді, коли її перевага перетворюється на критичну незамінність для інших.

> **Система не повинна штучно послаблювати сильний вузол; вона повинна зменшувати небезпечну залежність інших від нього.**

## 32.2. Civilization Dependency Graph {#s31-002}

TOS повинен мати окрему карту залежностей цивілізації.

Вона відстежує залежність від:

- одного джерела води;
- одного енергетичного вузла;
- одного постачальника продукту;
- одного родовища;
- одного виробника ліків;
- одного транспортного маршруту;
- одного програмного компонента;
- одного AI-провайдера;
- однієї технічної команди;
- одного зовнішнього клієнта чи джерела доходу;
- одного юридичного шлюзу.

Граф не визначає винних. Він показує, де сама архітектура створила leverage.

## 32.3. Залежність як системний борг {#s31-003}

Критична залежність розглядається як liability незалежно від того, чи є поточний постачальник дружнім.

Зменшення залежності може здійснюватися через:

- резерв;
- альтернативного постачальника;
- інший маршрут;
- переробку;
- технологічну заміну;
- зниження споживання;
- локалізацію частини виробництва;
- поширення критичного знання;
- створення нових команд компетенції.

## 32.4. Асиметрія залежності {#s31-004}

Особливо небезпечною є ситуація, коли вузол A критично залежить від B, а B майже не залежить від A.

TOS може окремо відстежувати **dependency asymmetry** і позначати випадки, де одна сторона отримує надмірну переговорну владу через фізичну або технологічну незамінність.

Метою не є створення штучної однаковості, а уникнення відносин, у яких одна сторона може без значних витрат для себе паралізувати іншу.

## 32.5. Essential Resource Protocol {#s31-005}

Якщо ресурс одночасно:

- критичний для базового життя або технологічної стійкості;
- важко замінюється;
- географічно або технологічно концентрований;
- необхідний багатьом незалежним вузлам,

до нього застосовується окремий протокол сумісності.

Оператор такого ресурсу зберігає економічні права й право на винагороду, але не отримує права використовувати bottleneck для політичного примусу.

Протокол може включати:

- прозорі правила доступу;
- заборону політичної дискримінації;
- передбачувані умови поставок;
- перехідний період для припинення критичних контрактів;
- незалежну перевірку обсягів і резервів;
- вимогу аварійних планів;
- стимули для розвитку альтернатив.

## 32.6. Civilizational Commons {#s31-006}

Деякі ресурси можуть мати характер цивілізаційних commons: річки, водоносні горизонти, критичні природні проходи, частотний спектр, незамінні екологічні системи або інші ресурси, де абсолютний локальний контроль створює прямий ризик для життя багатьох незалежних людей.

Це не означає автоматичного переходу ресурсу у власність федерації.

Можлива модель:

- локальна спільнота — steward;
- оператор — виробник або технічний керівник;
- користувачі — сторони з визначеними правами доступу;
- незалежний протокол — механізм перевірки й арбітражу.

## 32.7. Право на перевагу, але не право на гегемонію {#s31-007}

Комуна або людина може бути:

- багатшою;
- продуктивнішою;
- технологічно сильнішою;
- власником великої частки економічних активів;
- автором важливої технології.

Це не створює додаткових політичних голосів, права вето чи права вимагати політичної лояльності від залежних сторін.

## 32.8. Відкрите критичне знання як антимонопольний механізм {#s31-008}

Відкрите знання є не лише культурною цінністю, а структурним захистом від монополії.

Критичні технології повинні мати тенденцію до:

- документування;
- передачі компетенцій;
- незалежного відтворення;
- навчання альтернативних команд;
- довгострокової ремонтопридатності.

> **Знання, яке може бути відтворене багатьма, складніше перетворити на інструмент гегемонії.**

## 32.9. Безбанківське ризикове фінансування {#s31-009}

У базовій економічній моделі Вільнізму не передбачається необхідність класичної банківської системи, що концентрує чужі кошти й створює процентний борг як постійний механізм залежності.

Процентне кредитування грошей як спосіб гарантованого доходу з боргу не є базовим механізмом Вільнізму.

Фінансування проєктів може будуватися через:

- прямі ризикові інвестиції;
- кооперативне фінансування;
- спільне володіння результатом;
- краудфандинг;
- передоплату продукту;
- взаємні ресурсні угоди;
- безпроцентні тимчасові позики там, де вони добровільні й прозорі.

Інвестор приймає реальний ризик проєкту, а не отримує автоматичне право вимагати гарантованого приросту незалежно від результату.

## 32.10. Протокол маршрутизації капіталу {#s31-010}

TOS може допомагати знаходити й узгоджувати інвестиції, але не повинен сам ставати єдиним власником або розподілювачем капіталу.

Функція TOS:

- показати проєкт;
- показати ризики;
- зіставити сторони;
- зафіксувати умови;
- відстежити виконання;
- забезпечити прозорість спільного проєкту.

> **Інфраструктура може координувати ресурс, не володіючи ним.**

## 32.11. Вихід ресурсного вузла {#s31-011}

Право комуни на вихід з федеративної мережі зберігається навіть тоді, коли вона володіє критичним ресурсом.

Однак вихід не повинен автоматично стирати вже добровільно взяті зобов’язання.

Критичні договори можуть заздалегідь передбачати transition window, достатній для того, щоб залежні сторони створили альтернативу.

Політичний вихід і контрактна відповідальність — різні речі.

-----

-----

# 33. Біоміметична архітектура цивілізації

## 33.1. Межа біологічної аналогії {#s32-001}

Природа може бути джерелом архітектурних принципів, але люди не є клітинами, якими система має право жертвувати заради цілого.

Вільнізм бере з біології:

- модульність;
- зворотний зв’язок;
- спеціалізацію;
- резервування;
- адаптацію;
- локалізацію пошкоджень.

Він не бере принцип абсолютного пріоритету організму над окремою людиною.

## 33.2. Спеціалізація без однаковості {#s32-002}

Як клітини й органи можуть мати різні функції, комуни не повинні бути однаковими.

Система може підтримувати високу спеціалізацію, якщо критичні функції залишаються сумісними, а залежності — видимими й керованими.

Оптимальна модель:

> **мінімальна автономність для виживання + глибока добровільна спеціалізація для процвітання.**

## 33.3. Гомеостаз без центрального командування {#s32-003}

Багато процесів не потребують політичного голосування кожного разу.

TOS може працювати як homeostasis layer:

- вимірювати стан;
- визначати відхилення;
- сигналізувати;
- запускати заздалегідь погоджені локальні резервні процедури;
- пропонувати варіанти.

Але виявлення відхилення не створює автоматичного права на політичну централізацію.

## 33.4. Морфогенез через сигнали, а не накази {#s32-004}

Замість централізованого плану, який вирішує, де саме має виникнути кожен проєкт, мережа може публікувати локальні сигнали:

- дефіцит;
- надлишок;
- попит;
- екологічне навантаження;
- вільну енергію;
- доступні компетенції;
- ризик залежності.

Люди, кооперативи й комуни самостійно реагують на інформаційне поле.

## 33.5. Модульність і локалізація помилки {#s32-005}

Сильна система не повинна вимагати одночасної зміни всієї цивілізації.

Комуни й функціональні мережі є модулями, у яких можна:

- тестувати різні правила;
- локалізувати невдалий експеримент;
- порівнювати результати;
- переносити успішні рішення;
- не руйнувати всю мережу через локальну помилку.

## 33.6. Різнорідне резервування {#s32-006}

Стійкість не завжди означає дві однакові копії.

Для критичної функції бажано мати різні способи її виконання.

Наприклад енергетична стійкість може включати:

- сонячну генерацію;
- гідроенергію;
- накопичувачі;
- біопаливо;
- аварійний генератор;
- міжкомунний обмін.

Різні механізми зменшують ризик спільної відмови одного класу технологій.

## 33.7. Інституційний апоптоз {#s32-007}

Нездатність інституції припинити існування після втрати функції є системною патологією.

Комісії, надзвичайні органи, тимчасові фонди й спеціальні структури повинні мати механізми автоматичного саморозпуску.

Інституційний TTL (§31.7) є технічним аналогом цього принципу.

## 33.8. Резерв універсальних компетенцій {#s32-008}

Надмірна спеціалізація робить цивілізацію крихкою.

Поряд із вузькими професіями повинна існувати civilization stem capacity — резерв людей, навчальних програм і документації, здатний відновити критичні компетенції.

Можлива метрика:

- скільки критичних функцій можна відновити за 3, 6 і 12 місяців після втрати основної команди.

## 33.9. Розподілена імунна функція {#s32-009}

Виявлення системних патологій не повинно належати одному центральному органу.

До розподіленого захисту належать:

- red team;
- незалежні аудитори;
- взаємний аудит комун;
- зовнішні дослідники;
- whistleblower-канали;
- автоматичне виявлення аномалій.

Цей механізм аналізує владу, процеси й публічні залежності, а не перетворюється на тотальний нагляд за приватним життям.

## 33.10. Патологічний ріст як властивість структури, а не людини {#s32-010}

Небезпечним є не «погана людина» як біологічна метафора, а структура, яка:

- нескінченно накопичує ресурси й повноваження;
- перестає реагувати на механізми відкликання;
- робить себе незамінною;
- використовує ресурси цілого для власного самозбереження;
- блокує появу альтернатив.

Система повинна лікувати такі структури через розділення повноважень, альтернативи, форки, відкликання мандатів і зниження залежності, а не через дегуманізацію людей.

## 33.11. Bow-tie core {#s32-011}

Велика мережа може поєднувати величезну різноманітність через дуже малий універсальний core.

Для Вільнізму таким core можуть бути:

- базові права;
- правила доказів;
- переносимість;
- право на вихід;
- мінімальний формат міжкомунних договорів;
- сумісність ідентифікаційних доказів;
- аварійні протоколи;
- правила форків.

Core має бути мінімальним, відкритим, дубльованим і форкабельним, оскільки занадто складне або незамінне ядро саме стає single point of failure.

## 33.12. Small-world зв’язність {#s32-012}

Кожна комуна може мати багато сильних локальних зв’язків і невелику кількість далеких незалежних зв’язків з іншими регіонами.

Такі cross-cluster links:

- прискорюють поширення знань;
- зменшують регіональну ізоляцію;
- створюють альтернативні маршрути;
- ускладнюють формування закритих блоків.

## 33.13. Нерезонансні цикли {#s32-013}

Критичні цикли системи не повинні бути надмірно синхронізованими.

Ротації ролей, аудит, бюджетні цикли, оновлення TOS, перегляд канону й резервні навчання бажано розносити в часі, щоб одна дата або подія не створювала одночасний системний перехід.

Золотий перетин або інші математичні константи не проголошуються універсальними законами суспільства; важливішим є сам принцип уникнення простого резонансу й надмірної синхронізації.

## 33.14. Динамічний баланс замість статичної рівноваги {#s32-014}

Живі системи не є нерухомими. Вони постійно споживають енергію, ремонтуються й адаптуються.

Так само стійка цивілізація не повинна прагнути знайти одну остаточну форму.

> **Стабільність — це здатність безперервно змінюватися, не втрачаючи життєздатності, свободи й базових гарантій.**

## 33.15. Чотири виміри цивілізаційного балансу {#s32-015}

Для кожної критичної системи потрібно шукати не один максимум, а баланс між:

- **ефективністю** — мінімум зайвих ресурсів;
- **стійкістю** — здатністю пережити відмову;
- **адаптивністю** — здатністю перебудуватися;
- **автономією** — здатністю вузла не бути заручником цілого.

Різні сфери можуть мати різні оптимальні співвідношення. Вода, медицина, мікрочипи й governance не повинні мати одну універсальну формулу.

-----

-----

# 34. Криптографічна довіра, приватність і мережеві принципи

## 34.1. Blockchain як доказовий, а не владний шар {#s33-001}

Розподілений журнал може бути корисним там, де кілька незалежних сторін повинні мати перевірювану спільну історію без довіри до одного архіваріуса.

До такого шару можуть виноситися:

- хеші версій канону;
- результати голосувань;
- федеративні мандати;
- активація й завершення кризових повноважень;
- міжкомунні договори;
- аудиторські докази;
- бюджети спільних проєктів.

Але blockchain не визначає істину або моральну правильність рішення.

> **Люди та процедури ухвалюють рішення; криптографія лише допомагає довести, що історію не було тихо переписано.**

## 34.2. Permissioned ledger для відомих федеративних вузлів {#s33-002}

Для частини міжкомунних задач можливий приватний або permissioned ledger, де валідаторами є відомі незалежні вузли, а не необмежена анонімна мережа.

Критична дія може вимагати підтвердження кількох незалежних trust domains.

Жоден вузол не повинен одноосібно:

- переписувати історію;
- змінювати мандат;
- видаляти договір;
- активувати надзвичайне повноваження.

## 34.3. Незмінні докази, але змінні правила {#s33-003}

Вільнізм розрізняє:

- незмінність доказу минулого;
- змінність правил майбутнього.

> **Past immutable; future forkable.**

Історію не можна тихо переписати. Але невдале правило повинно бути можливо змінити, скасувати або форкнути.

## 34.4. Принцип мінімального розкриття {#s33-004}

Система повинна доводити лише ті властивості людини, які потрібні для конкретної дії.

Замість глобального профілю можуть використовуватися докази типу:

- особа є унікальним учасником;
- має право голосувати в цьому питанні;
- досягла необхідного віку;
- ще не використала цей бюлетень;
- має потрібну професійну кваліфікацію.

Доказ права не повинен автоматично розкривати всю особистість.

## 34.5. Розділення eligibility та voting identity {#s33-005}

Для приватного голосування необхідно одночасно захистити систему від Sybil-атак і не створити глобальну історію політичних поглядів людини.

Можлива архітектура:

1. локальний eligibility layer перевіряє унікальність і право участі;
2. людині видається privacy-preserving credential;
3. голосування використовує credential без розкриття реальної особи;
4. система перевіряє одноразовість голосу;
5. індивідуальний вибір не може бути зв’язаний із громадянином.

## 34.6. Різні режими прозорості для різних ролей {#s33-006}

Приватність належить людині. Підзвітність належить ролі.

Тому:

- приватний голос громадянина може бути таємним;
- використання делегованого мандату представником має бути публічним;
- експертна рекомендація має бути атрибутованою разом із конфліктами інтересів;
- бюджетна дія посадової особи має бути перевірюваною.

## 34.7. Перевірюване таємне голосування {#s33-007}

Якщо застосовується електронне голосування, система повинна прагнути одночасно забезпечити:

- право голосу лише допустимих учасників;
- один голос на допустимого учасника там, де діє принцип «одна людина — один голос»;
- таємницю індивідуального вибору;
- неможливість непомітно додати або видалити бюлетені;
- незалежну перевірюваність фінального підрахунку;
- захист від купівлі голосів і примусу настільки, наскільки це технічно досяжно.

Zero-knowledge proofs, threshold cryptography, mixnets та інші криптографічні механізми можуть бути дослідницькими інструментами для реалізації цих властивостей.

Конкретна технологія не канонізується: канонізуються вимоги до властивостей.

## 34.8. Threshold control {#s33-008}

Критичний ключ не повинен належати одній людині.

Можливі схеми, де дія дозволяється лише при участі визначеного порогу незалежних сторін, наприклад кількох із набору trustees.

Це може застосовуватися до:

- розшифрування підсумку голосування;
- аварійного доступу;
- великих трансферів спільної скарбниці;
- відновлення master-ключів;
- підписання критичних релізів.

## 34.9. Принцип локального знання за аналогією з onion routing {#s33-009}

Кожен вузол повинен знати лише ту частину інформації, яка необхідна для його функції.

Наприклад:

- медичний модуль не потребує політичної історії;
- голосувальний модуль не потребує медичних даних;
- логістичний вузол не потребує повного діагнозу одержувача;
- федеративний агрегатор не потребує індивідуальних бюлетенів;
- платіжний або ресурсний маршрут не повинен створювати універсальний профіль особи.

Це сильніше за просте шифрування єдиної центральної бази: повна база не повинна існувати без необхідності.

## 34.10. Незалежні маршрути перевірки {#s33-010}

Критичний аудит або підтвердження не повинні проходити лише через вузли одного соціального, економічного або географічного домену.

Бажано, щоб verification path перетинав незалежні trust domains.

Це зменшує ризик прихованої змови одного локального кластера.

## 34.11. Privacy-preserving канали звернення {#s33-011}

Мережа повинна дозволяти безпечне звернення до:

- незалежного арбітра;
- whistleblower-каналу;
- медичної допомоги;
- кризової підтримки;
- зовнішнього аудитора

без обов’язкового попереднього розкриття звернення локальному керівництву.

## 34.12. Selective transparency {#s33-012}

Прозорість системи й приватність людини не є суперечністю.

Публічними за замовчуванням повинні бути:

- правила;
- владні мандати;
- спільні бюджети;
- використання примусових повноважень;
- зміни критичного коду;
- методики підрахунку.

Приватними за замовчуванням повинні бути:

- індивідуальний політичний вибір;
- медицина;
- приватне листування;
- особисті фінанси, якщо вони не пов’язані з публічним мандатом;
- особисте життя;
- дані, не потрібні для конкретної функції.

> **Система максимально прозора щодо власної влади й максимально стримана щодо даних людини.**

## 34.13. Forkability мережевої інфраструктури {#s33-013}

Критичні протоколи, журнали, Canon Studio й TOS повинні бути відтворюваними незалежними командами.

У разі фундаментальної незгоди спільна перевірена історія може зберігатися до точки форку, після чого різні гілки розвиваються незалежно.

Технічна архітектура не повинна робити політичний форк фізично неможливим.

## 34.14. Відмова від технологічного догматизму {#s33-014}

Blockchain, Tor, zero-knowledge proofs, mixnets та permissioned ledgers є джерелами корисних принципів, але не обов’язковими технологіями для кожного процесу.

Критерій використання:

- чи зменшує технологія довіру до одного центру;
- чи покращує приватність;
- чи підвищує перевірюваність;
- чи не створює нової незамінної технічної касти;
- чи існує простіший механізм із тими самими властивостями.

-----

-----

# 35. Vilnism Survival Standard і протокол відновлення цивілізації (новий розділ, додано у v0.7)

## 35.1. Вихідний принцип {#s34-001}

Цивілізаційна стійкість не повинна залежати лише від запасів, складів, електромережі, серверів або наявності конкретної громади. Найгірший сценарій для перевірки системи — людина або мала група вижила, але втратила майже все: житло, обладнання, транспорт, зв’язок, документи, локальну інфраструктуру і доступ до зовнішніх поставок.

У такому сценарії Вільнізм ставить технічне питання:

> **Який мінімальний набір знань, алгоритмів, інструментів і відкритих технологій дозволяє людині послідовно пройти шлях від першої безпечної ночі до стабільного поселення, а групі спеціалістів — далі до відновлення складної цивілізаційної інфраструктури?**

Відповіддю є два взаємопов’язані стандарти:

- **VSS — Vilnism Survival Standard**: базові навички, пристрої, відкриті конструкції, тести й протоколи для води, тепла, укриття, вогню, їжі, санітарії, медицини, енергії, зв’язку, навігації та ремонту.
- **VCRP — Vilnism Civilization Reboot Protocol**: послідовність переходу від виживання окремої людини до табору, поселення, локального виробництва, промислової бази та відновлення сучасних технологічних контурів.

VSS і VCRP є не культом катастрофи, а резервною цивілізаційною грамотністю. Їхня мета — зменшити паніку, залежність від крихкої інфраструктури й ціну великої системної помилки.

## 35.2. Не «рюкзак», а відтворювана система {#s34-002}

Критична помилка звичайного survival-підходу — ототожнювати стійкість із володінням набором речей. Рюкзак можна втратити, склад може згоріти, батарея деградує, фірмовий картридж зникає з ринку.

Тому VSS будується в чотирьох шарах:

1. **Knowledge** — людина розуміє пріоритети, базову фізику, біологію, ризики і способи імпровізації.
2. **Pocket Core** — компактний набір технологічно складних речей, які важко швидко відтворити з природних матеріалів.
3. **Commune Kit** — більші модулі громади, інструменти, запаси, лабораторні засоби, резервні генератори, фільтри, радіо й майстерні.
4. **Rebuild Knowledge Base** — офлайн-архів креслень, процедур, матеріалознавства, виробничих ланцюгів і технологічних залежностей для переходу від примітивної бази до сучасної техніки.

> **Втратити обладнання допустимо. Втратити здатність відновити базову функцію — ні.**

## 35.3. Алгоритм першого рішення {#s34-003}

Людина не повинна запам’ятовувати сотні розрізнених «лайфхаків». Вона має вміти запускати простий цикл оцінки:

**Загроза → час → середовище → люди → ресурси → пріоритет → дія → перевірка → наступний пріоритет.**

Перед будь-якою роботою оцінюються:

- безпосередні загрози життю;
- травми та стан людей;
- скільки світлого часу залишилось;
- температура, вітер, опади, вода, рельєф;
- ризик повені, пожежі, падіння дерев, зсуву, тварин, токсичних речовин або нестабільних конструкцій;
- кількість людей і їхні реальні можливості;
- наявні інструменти та матеріали;
- шанс на швидкий порятунок або евакуацію;
- ціна помилки та оборотність рішення.

Типова послідовність не є жорсткою догмою, але стартова рамка така:

1. **Негайна безпека і перша допомога.**
2. **Безпечне місце та терморегуляція.**
3. **Укриття до настання критичних погодних умов або ночі.**
4. **Надійна вода.**
5. **Вогонь/тепло, якщо вони потрібні середовищем.**
6. **Санітарія.**
7. **Сигналізація, зв’язок і навігація.**
8. **Їжа та її безпечне зберігання.**
9. **Енергія, ремонт і стабілізація побуту.**
10. **Перехід від тимчасового табору до стійкої системи.**

Пріоритет завжди визначається реальною загрозою. У холоді укриття й тепло можуть бути важливішими за пошук їжі; при тяжкій травмі медицина передує будівництву; при близькому гарантованому порятунку сигналізація може мати вищий пріоритет за довгострокове облаштування.

## 35.4. Одна людина і група {#s34-004}

Для однієї людини головний дефіцит — час, фізична сила й увага. Вона виконує задачі послідовно, уникає надмірно складних конструкцій і зберігає запас сил.

Для групи після первинної оцінки задачі розпаралелюються. Типові функції:

- оцінка місця й ризиків;
- укриття;
- вода;
- вогонь і паливо;
- медицина;
- збір матеріалів;
- сигналізація/зв’язок;
- санітарія;
- облік запасів і стану людей.

Ролі не є кастами. Вони змінюються, дублюються і мають резерв. Мінімум дві людини, де це можливо, повинні розуміти кожну критичну функцію.

Цей підхід є практичним продовженням кризової координації §12.4: структура управління не повинна бути складнішою за саму задачу виживання.

## 35.5. VSS Core: фундаментальні функції {#s34-005}

VSS не фіксує назавжди конкретну кількість товарів. Він фіксує **функції**, які мають бути закриті. Робочий базовий каталог може містити приблизно 30–50 модулів.

### 35.5.1. Вода {#s34-006}

1. Ручний мембранний мікрофільтр.
2. Гравітаційна система фільтрації.
3. Модуль попереднього відстоювання й механічного очищення.
4. Вугільний/адсорбційний модуль там, де він доречний.
5. Метод термічного знезараження.
6. Сонячна дистиляція.
7. Збір дощової води.
8. Збір роси або туману в придатному кліматі.
9. Ручний насос.
10. Ємності та стандартизовані з’єднання для безпечного зберігання й транспортування.

Жоден пристрій не має рекламуватися формулою «робить будь-яку воду безпечною». Біологічне забруднення, солі, важкі метали, органічні токсини й радіологічні забруднювачі потребують різних методів. Кожна VSS-система повинна мати чітко вказані межі застосування й процедуру перевірки.

### 35.5.2. Вогонь, тепло і приготування {#s34-007}

11. Ferro-rod або інше довговічне кресало.
12. Резервний механічний/п’єзоелектричний запалювач.
13. Сонячний концентратор як незалежний метод у відповідних умовах.
14. Стандартизований tinder-модуль і метод його локального відтворення.
15. Проста польова піч.
16. Rocket stove або інша високоефективна піч із локальних матеріалів.
17. Тепловідбивний екран.
18. Система сушіння й захисту палива від вологи.

### 35.5.3. Укриття {#s34-008}

19. Універсальний водостійкий тент.
20. Мотузкова система кріплень.
21. Теплоізоляційний bivy/спальний модуль.
22. Стандарти побудови укриттів із локальної деревини, землі, каменю, снігу чи інших доступних матеріалів.
23. Прості модульні кріплення, які дозволяють багаторазово збирати й розбирати конструкцію.

### 35.5.4. Енергія і світло {#s34-009}

24. Довготривалий LED-модуль.
25. Metal-air / saltwater-activated аварійний ліхтар.
26. Універсальний механічний Generator Core.
27. Ручний або педальний привід.
28. Адаптер для водяного колеса.
29. Адаптер для вітряного ротора.
30. Гравітаційний накопичувач.
31. Малий сонячний модуль.
32. Невеликий електричний буфер — суперконденсатор або довговічний акумулятор там, де він виправданий.

### 35.5.5. Зв’язок, навігація і сигналізація {#s34-010}

33. Автономний радіоприймач.
34. Простий локальний radio/LoRa/mesh-вузол там, де дозволено й технічно доцільно.
35. Компас і паперова навігація.
36. Свисток, сигнальне дзеркало, світловідбивач і світловий сигнал.
37. Водостійкий локальний каталог частот, карт і процедур зв’язку.

### 35.5.6. Санітарія і медицина {#s34-011}

38. Базовий модуль першої допомоги.
39. Простий пристрій для миття рук із мінімальною витратою води.
40. Польова система туалету й ізоляції відходів.
41. Засоби очищення інструментів і поверхонь відповідно до перевірених протоколів.
42. Захист від сонця, холоду, комах і травм середовища.

### 35.5.7. Їжа і зберігання {#s34-012}

43. Універсальна металева ємність для приготування.
44. Простий сонячний/повітряний дегідратор.
45. Методи сушіння, соління, ферментації та іншого безпечного збереження там, де вони культурно й санітарно перевірені.
46. Набір насіння для довшого сценарію з документацією по регіонах.
47. Базові інструменти для ґрунту й локального вирощування.

### 35.5.8. Інструменти і ремонт {#s34-013}

48. Мультитул або невеликий набір стандартних ручних інструментів.
49. Ріжучий інструмент.
50. Пилка.
51. Мотузка, стропа й дріт.
52. Стандартизовані кріплення.
53. Ремонтний комплект для тканини, шлангів, електропроводки й простих механізмів.
54. Вимірювальний мінімум: лінійка, базовий мультиметр/тестер там, де доступний, прості шаблони й калібри.

Каталог є відкритим: модулі можуть об’єднуватися, видалятися або замінюватися, якщо нове рішення виконує ту саму функцію простіше, надійніше й доступніше.

## 35.6. Інженерні правила VSS {#s34-014}

Кожен критичний пристрій проходить однаковий дизайн-фільтр:

- **Простота:** мінімум деталей і дій користувача.
- **Відтворюваність:** креслення й специфікація достатні для незалежного виробництва.
- **Ремонтопридатність:** розбирання звичайними інструментами без навмисно закритих вузлів.
- **Стандартні інтерфейси:** різьби, шланги, електричні напруги, кріплення й механічні вали не повинні бути без потреби пропрієтарними.
- **Доступні витратні матеріали:** перевага солі, воді, стандартним металам, тканині, деревині й іншим поширеним матеріалам перед ексклюзивними картриджами.
- **Довге зберігання:** пристрій не повинен втрачати критичну функцію лише через роки без використання.
- **Видима деградація:** користувач повинен розуміти, що зношується й коли потрібна заміна.
- **Безпечна відмова:** поломка не повинна створювати непропорційну нову небезпеку.
- **Локальна заміна:** критична частина має мати таблицю допустимих аналогів.
- **Відсутність серверної залежності:** базова функція працює без акаунта, хмари, ліцензійного сервера й мобільного застосунку.
- **Open hardware:** CAD, BOM, схеми, прошивки, методи випробування й ремонтна документація максимально відкриті.
- **Версіонованість:** кожна конструкція має версію, сумісність, історію змін, відомі дефекти й результати тестів.

Культурний принцип серії:

> **Bring intelligence, not mass — перенось складність, яку важко відтворити; використовуй локальну масу й прості ресурси там, де вони вже існують.**

Тому VSS має носити генератор, підшипник, мембрану, магніт, LED або точний інструмент, але не каміння, пісок, баласт чи іншу масу, яку можна безпечним способом знайти на місці.

## 35.7. VSS-Light: saltwater / metal-air світло {#s34-015}

Робоча концепція аварійного ліхтаря базується не на «енергії солоної води», а на електрохімічному елементі. Вода з електролітом активує систему, а витратний метал — наприклад, магній, алюміній або цинк у конкретно перевіреній конструкції — є реагентом, що поступово витрачається.

Проєктний напрям:

- окремий стандартний LED-модуль;
- змінний металевий анод;
- довговічний повітряний катод;
- камера, яку можна промити;
- OFF-режим, у якому електрод фізично відділений від електроліту або електроліт злитий;
- DC/DC стабілізація;
- мінімум електроніки;
- прозорий індикатор стану анода;
- можливість використовувати підготовлений електроліт або придатну природну солону воду лише в межах специфікації;
- відкриті розміри й склад змінного елемента.

Такий ліхтар не є «вічним» у буквальному фізичному сенсі: метал витрачається. Його мета — зробити корпус і технологічно складні компоненти довговічними, а «паливо» — простим, стандартизованим і доступним.

## 35.8. VSS-Power: універсальне механічне ядро {#s34-016}

Замість окремого генератора для кожного джерела руху VSS прагне до одного **Generator Core** із універсальним валом і стандартизованою електричною частиною.

До нього можуть підключатися:

- ручка;
- педалі;
- водяне колесо;
- вітряний ротор;
- гравітаційний вантаж;
- інший безпечний механічний привід.

Generator Core містить те, що важко відтворити в польових умовах: магнітну систему, котушки, підшипники, вал, випрямлення, захист і стабілізацію напруги. Корпус, привід, опору, частину редуктора або джерело механічної енергії за можливості можна відтворювати локально.

## 35.9. VSS-Gravity: зберігання енергії у висоті {#s34-017}

Гравітаційний модуль використовує простий принцип: надлишкова робота піднімає масу, а контрольований спуск пізніше обертає генератор.

Його переваги:

- практично відсутнє старіння самого «носія» енергії;
- не потрібна хімічна батарея великої ємності;
- локальну масу можна отримати з каміння, піску, води або інших доступних матеріалів;
- стан запасу енергії візуально зрозумілий;
- механізм можна ремонтувати.

Його фундаментальне обмеження — низька щільність енергії. Запас визначається добутком маси, прискорення вільного падіння й висоти. Тому VSS-Gravity розглядається насамперед як накопичувач для малопотужного світла, радіо, датчиків та інших невеликих навантажень, а не як компактна заміна великій електричній батареї.

Польова версія повинна використовувати безпечну опору, блоки, храповик, контроль швидкості та захищену зону падіння. Випадкове підвішування великих вантажів над людьми або табором не є допустимим VSS-методом.

## 35.10. Вода з повітря: кліматично залежна функція {#s34-018}

VSS не приймає маркетингову тезу про універсальний «пристрій, що добуває воду в будь-якій пустелі». Кількість води в повітрі й енергія конденсації залежать від температури, відносної та абсолютної вологості.

Тому стандарт передбачає кілька методів:

- збір туману;
- збір роси;
- дощозбір;
- сонячну дистиляцію;
- активну конденсацію лише там, де доступна достатня енергія;
- регіональні карти ефективності.

Пристрій вважається VSS-сумісним лише тоді, коли документація чесно показує умови, за яких він дає практично значущий обсяг води.

## 35.11. Pocket Core {#s34-019}

Pocket Core — не повний survival-рюкзак, а мінімальний набір високої «технологічної щільності».

Його склад визначається масою, кліматом і місією, але типовими кандидатами є:

- якісний ferro rod;
- мембранний фільтр;
- компактний універсальний інструмент;
- міцний шнур;
- LED-модуль;
- мінімальний Generator Core або його компактна версія;
- базовий медичний модуль;
- компактна аварійна теплоізоляція;
- паперовий VSS Quick Protocol;
- локальна офлайн-копія ключових інструкцій.

VSS не вимагає від кожної людини постійно носити однаковий комплект. Важливо, щоб критичні знання не були прив’язані до наявності конкретної речі.

## 35.12. Commune Kit {#s34-020}

На рівні комуни додаються системи, які недоцільно дублювати для кожної людини:

- великі водні фільтри й тестування якості води;
- насоси й резервуари;
- резервні енергетичні модулі;
- інструментальна майстерня;
- радіомережа;
- медичні запаси й обладнання;
- насіннєвий банк;
- ремонтні матеріали;
- вимірювальні прилади;
- локальні сервери й бібліотека;
- друковані карти та протоколи;
- запас стандартних підшипників, магнітів, електронних компонентів, мембран та інших деталей, які важко виготовити з нуля;
- виробничі шаблони, оснастка і калібри.

Комуна зберігає не лише готові речі, а **здатність їх виробляти й ремонтувати**.

## 35.13. VCRP: драбина від виживання до цивілізації {#s34-021}

VCRP описує не календарну обіцянку, а рівні спроможності.

### VCRP-0 — Survive {#s34-022}

Горизонт: перші години й перша доба.

Функції:

- безпека;
- перша допомога;
- місце;
- терморегуляція;
- укриття;
- вода;
- сигналізація.

### VCRP-1 — Stabilize {#s34-023}

Горизонт: перші дні.

Функції:

- стабільне джерело води;
- санітарія;
- вогонь і приготування;
- сухе житло;
- базовий облік ресурсів;
- ремонт;
- зв’язок;
- безпечне зберігання їжі.

### VCRP-2 — Camp {#s34-024}

Група переходить від реакції до організованого табору:

- ролі;
- резервування компетенцій;
- графіки;
- зона води;
- зона гігієни;
- кухня;
- медична зона;
- майстерня;
- склад;
- правила пожежної й санітарної безпеки;
- канал зв’язку і журнал рішень.

### VCRP-3 — Settlement {#s34-025}

Формується стійке поселення:

- постійне водопостачання;
- виробництво частини їжі;
- енергетика;
- ремонтна майстерня;
- медицина;
- будівництво;
- локальна мережа;
- освіта;
- запаси й резервні контури.

### VCRP-4 — Civilization Bootstrap {#s34-026}

Відновлюються базові виробничі ланцюги:

- деревообробка;
- кераміка;
- вапно/цементні технології відповідного рівня;
- металообробка;
- механіка;
- скло;
- електрика;
- генератори;
- насоси;
- стандарти деталей;
- вимірювання;
- друк і тиражування знань;
- лабораторна культура;
- агрономія.

### VCRP-5 — Industrial Recovery {#s34-027}

Мета — повернути здатність масово виготовляти складніші засоби:

- верстати;
- точну механіку;
- двигуни;
- стабільні електромережі;
- промислову хімію з жорстким контролем безпеки;
- стандартизовані матеріали;
- транспорт;
- розвинуті лабораторії;
- фармацевтичні й медичні виробничі контури там, де відновлена відповідна компетентність і контроль якості.

### VCRP-6 — Modern Technology {#s34-028}

Лише після відновлення достатньої наукової та виробничої бази:

- електроніка;
- обчислювальна техніка;
- сучасний радіозв’язок;
- автоматизація;
- точне приладобудування;
- складні медичні системи;
- напівпровідникові й оптичні технології.

Критична ідея: VCRP не обіцяє, що 20 людей самотужки швидко побудують сучасний чіп. Він показує **залежності**, необхідні для того, щоб група не втратила напрямок від простого інструмента до складної технологічної екосистеми.

## 35.14. Technology Ladder {#s34-029}

Кожна складна технологія розкладається на дерево залежностей.

Приклади:

**Механічна гілка:**

камінь/різальний край → обробка деревини → мотузка → важіль → блок → колесо/вісь → підшипник → редуктор → генератор → електродвигун → верстат → точна механіка.

**Водна гілка:**

збір → відстоювання → знезараження → фільтрація → зберігання → ручний насос → механізований насос → резервуар → локальний водопровід → каналізація → лабораторний контроль.

**Харчова гілка:**

збір → вирощування → насіння → ґрунт → полив → зберігання → ферментація/сушіння → сільське господарство → механізація → селекція й лабораторний контроль.

**Інформаційна гілка:**

усна передача → піктограма/письмо → паперовий архів → друк → стандартизовані довідники → локальні цифрові копії → мережа → обчислення → автоматизовані системи знань.

Technology Ladder повинна містити не лише «як зробити», а й **що потрібно вміти до цього**, які матеріали критичні, які вузли складно відтворити й де виникають небезпечні переходи.

## 35.15. Build from Kit / Build from Environment / Build the Toolchain {#s34-030}

Для кожного VSS-модуля документація має три режими:

1. **Build from Kit** — складання зі стандартизованих компонентів.
2. **Build from Environment** — відновлення функції з доступних локальних матеріалів, коли оригінальний модуль втрачено.
3. **Build the Toolchain** — пояснення, як із простіших технологій відновити інструменти й виробничий ланцюг, потрібні для виготовлення самого модуля.

Саме третій режим перетворює survival-документацію на цивілізаційний архів.

## 35.16. Освіта з дитинства: спіраль компетентності {#s34-031}

Навчання VSS/VCRP не будується як іспит на виживання або культ жорсткості. Воно має бути безпечним, віковим, практичним і добровільно-дослідницьким.

Робоча модель:

### Ранній рівень {#s34-032}

Дитина розуміє:

- базові небезпеки;
- де безпечне й небезпечне місце;
- навіщо потрібна чиста вода;
- що таке тепло, холод, вітер і волога;
- як подати сигнал;
- як попросити допомогу;
- як працюють важіль, блок, колесо, простий фільтр;
- чому невідома вода або рослина не стає безпечною лише тому, що виглядає чистою.

### Середній рівень {#s34-033}

Підліток може під наглядом:

- зібрати просте укриття;
- організувати безпечне місце для води й санітарії;
- користуватися кількома методами розпалювання;
- зібрати базовий фільтраційний контур;
- працювати з ручними інструментами;
- зробити простий механізм;
- зрозуміти генерацію електрики;
- зібрати базову систему освітлення;
- користуватися картою, компасом і радіо;
- виконувати базові дії першої допомоги відповідно до навчальної програми.

### Старший базовий рівень {#s34-034}

Людина розуміє:

- будівельні принципи;
- електрику;
- прості генератори й двигуни;
- водні системи;
- харчове зберігання;
- ґрунт і вирощування;
- локальні мережі;
- ремонт;
- базове матеріалознавство;
- групову кризову координацію;
- межі власної компетентності.

### Спеціалізований рівень {#s34-035}

Далі формуються інженери, медики, агрономи, будівельники, енергетики, зв’язківці, матеріалознавці, програмісти та інші спеціалісти. Вони не замінюють базову грамотність інших, а поглиблюють окремі гілки Technology Ladder.

Ціль освіти — не щоб кожна дитина могла самостійно «відтворити сучасну цивілізацію», а щоб кожне покоління розуміло її фундамент, а об’єднана мережа спеціалістів могла відновлювати дедалі вищі технологічні рівні.

## 35.17. Вчити принцип, а не бренд пристрою {#s34-036}

VSS вважає недостатнім навчити користуватися готовою річчю.

Приклади:

- не лише «ось фільтр», а розмір частинок, тиск, адсорбція, знезараження й межі кожного методу;
- не лише «ось генератор», а провідник, магнітне поле, відносний рух, випрямлення і стабілізація;
- не лише «ось піч», а паливо, кисень, температура, тяга й теплообмін;
- не лише «ось укриття», а теплопровідність, конвекція, випаровування, вітер, волога й випромінювання;
- не лише «ось акумулятор», а різниця між виробленням, накопиченням і перетворенням енергії.

Технологія має бути настільки зрозумілою, щоб при втраті конкретної моделі людина могла відновити **функцію**, а не чекати на оригінальну запчастину.

## 35.18. Стандарт документації: одна картка — одна функція {#s34-037}

Для польового використання кожен модуль має коротку картку:

- ідентифікатор і версію;
- функцію;
- умови застосування;
- що потрібно;
- схему;
- послідовність складання/використання;
- перевірку результату;
- типові відмови;
- небезпечні помилки;
- альтернативні матеріали;
- коли метод не працює;
- посилання на повну документацію.

Коротка картка повинна бути придатною для друку й використання без інтернету.

Повний пакет містить:

- CAD/STEP/STL, де доречно;
- електричні схеми;
- BOM;
- допустимі заміни;
- специфікації матеріалів;
- ремонт;
- ресурс вузлів;
- критерії браку;
- тестові процедури;
- результати випробувань;
- історію версій;
- навчальні матеріали;
- Technology Ladder dependencies.

QR-код може вести на цифрову версію, але паперовий мінімум і локальний офлайн-архів є обов’язковими.

## 35.19. VSS як постійно вдосконалюваний «еталонний продукт» {#s34-038}

VSS має розвиватися так само систематично, як найкращі інженерні продукти:

- кожна версія порівнюється з попередньою;
- реальні польові тести фіксуються;
- зайві деталі видаляються;
- маса й об’єм зменшуються без втрати функції;
- рідкісні матеріали замінюються поширенішими;
- кількість спеціальних інструментів скорочується;
- дитяча зрозумілість конструкції вимірюється окремо від професійної ефективності;
- час розгортання вимірюється;
- ремонт у польових умовах тестується;
- незалежні команди намагаються відтворити пристрій лише з опублікованої документації;
- red-team шукає небезпечні способи неправильного використання;
- невдалі конструкції лишаються в історії разом із причиною відмови.

VSS не є брендовою монополією. Сумісний пристрій може виробляти будь-хто, якщо він проходить відкриті критерії стандарту.

## 35.20. Критерії VSS-сумісності {#s34-039}

Пристрій або протокол не отримує статус VSS лише тому, що він «простий» або здається корисним.

Мінімальні критерії:

1. функція чітко визначена;
2. межі застосування описані;
3. ризики й небезпечні відмови відомі;
4. існує відтворюваний тест;
5. документація відкрита;
6. немає штучної залежності від одного виробника;
7. базова функція доступна офлайн;
8. є процедура ремонту або заміни;
9. ресурс і витратні матеріали відомі;
10. результат незалежно повторений;
11. для критичних функцій існує резервний метод на іншому фізичному принципі, де це практично можливо;
12. пристрій проходить перевірку реальними користувачами різного віку й досвіду.

## 35.21. Метрики цивілізаційної автономності {#s34-040}

До KPI стійкості можуть додаватися:

- час від втрати інфраструктури до безпечного базового табору;
- час до відновлення надійної води;
- час до автономного мінімального енергоконтру;
- частка критичних функцій із двома незалежними методами;
- частка VSS-пристроїв, які незалежна команда може відтворити з документації;
- частка компонентів, що мають локальні аналоги;
- середній строк зберігання критичних модулів;
- час навчання базовому VSS-рівню;
- частка населення, здатна виконати VCRP-0/1 без цифрового асистента;
- кількість спеціалістів-дублерів на критичну функцію;
- максимальний технологічний рівень, який конкретна комуна може відновити з локальних ресурсів і наявного архіву;
- залежність від зовнішніх вузлів для кожної гілки Technology Ladder.

Ці метрики оцінюють **систему підготовки**, а не використовуються як соціальний рейтинг людей.

## 35.22. Регулярні симуляції {#s34-041}

Готовність не перевіряється лише на папері.

Можливі безпечні навчальні режими:

- кілька годин без електромережі;
- день із локальною водною системою;
- розгортання табору з обмеженим набором інструментів;
- відновлення зв’язку без інтернету;
- складання VSS-пристрою з незнайомого комплекту за документацією;
- групова задача з розподілом ролей;
- евакуаційне тренування;
- «втрата» одного ключового спеціаліста в симуляції, щоб перевірити резерв компетенцій;
- перевірка паперових інструкцій людьми, які не брали участі в їх написанні.

Симуляції не повинні навмисно створювати реальний дефіцит води, медичної допомоги, сну чи безпеки заради «загартування». Мета — знайти дефекти системи без нанесення шкоди учасникам.

## 35.23. Безпека знань і межі імпровізації {#s34-042}

Відкрите критичне знання не означає романтизацію небезпечного експериментування.

Особливо високий поріг перевірки потрібен для:

- питної води;
- медицини;
- електрики високої потужності;
- підйому великих вантажів;
- тиску й газів;
- токсичних речовин;
- складної хімії;
- конструкцій, падіння яких може травмувати людей;
- вогню в сухому або закритому середовищі.

Якщо польовий метод не дозволяє перевірити безпеку результату, VSS має прямо говорити про невизначеність, а не створювати фальшиве відчуття контролю.

## 35.24. Civilization Recovery Archive {#s34-043}

VSS/VCRP має існувати одночасно у кількох формах:

- короткий друкований польовий довідник;
- повна друкована енциклопедія залежностей;
- локальний цифровий архів;
- репліки у багатьох комунах;
- відкритий Git/Canon as Code репозиторій;
- машинозчитувані графи технологічних залежностей;
- навчальні симуляції;
- переклади;
- довгострокові фізичні носії для найбільш фундаментального знання.

Архів має відповідати принципу різнорідного резервування §33.6: одна й та сама критична інформація не повинна залежати від одного формату, однієї мови, одного сервера чи одного типу носія.

## 35.25. Підсумковий принцип {#s34-044}

Високотехнологічна цивілізація стає стійкішою не тоді, коли кожна людина постійно виконує примітивну ручну працю, а тоді, коли автоматизація максимально звільняє її в нормальному режимі, **але знання про фундаментальні функції не зникає**.

> **Найкращий VSS — не той, що робить людину залежною від ідеального survival kit, а той, що навчає її розуміти пріоритети, фізичні принципи й технологічні залежності настільки добре, що після втрати комплекту вона здатна відновити функції знову.**

У граничній формі VSS/VCRP є «компресованою цивілізацією»: базове ядро знань знаходиться в людях, деталізоване — у розподіленому архіві, а складні технології представлені як відкрите дерево залежностей, яке кожне покоління може перевіряти, спрощувати й розвивати.

## 35.26. Civilization Technology Stack: рівні як capability-профіль {#s34-045}

Technology Ladder доповнюється стандартним стеком рівнів. Це не «епохи», не оцінка цінності суспільства і не вимога пройти історію людства в заданому порядку. Різні гілки одного поселення можуть одночасно перебувати на різних рівнях.

- **L0 — Survival:** безпечна вода, тепло, укриття, санітарія, базова перша допомога, сигналізація.
- **L1 — Craft:** дерево, кераміка, прості метали, ручні інструменти, локальні матеріали, ремонт базових предметів.
- **L2 — Mechanical:** стандартизовані механічні вузли, насоси, передачі, вальці, токарні/свердлильні операції, механічна енергія.
- **L3 — Electrical:** генерація, базові двигуни, акумуляція, проводка, реле, прості електричні вимірювання.
- **L4 — Industrial:** стандартизовані матеріали, хімічні процеси з контролем якості, масове машинобудування, мембрани, точні компоненти.
- **L5 — Digital:** мікроконтролери, обчислення, локальні мережі, автоматизація, цифрові архіви та TOS.
- **L6 — Autonomous:** роботизоване виробництво, AI-оркестрація, автоматичні лабораторії, самодіагностика й планування ремонтів.
- **L7 — Advanced:** технології, що потребують глибоких багаторівневих supply chains: напівпровідники, складна біотехнологія, прецизійна оптика та інші системи відповідного рівня.

Вищий рівень не скасовує нижчий. Стійка цивілізація зберігає знання та перевірені fallback-маршрути вниз.

## 35.27. Graceful Technological Degradation {#s34-046}

Для кожної критичної функції Civilization OS зберігає не одну «правильну» реалізацію, а **ланцюг деградації**.

При втраті мікроконтролера автоматичний насос може перейти на ручне керування; при втраті електрики — на механічний або гравітаційний режим; при втраті заводського картриджа — на нижчий локально відтворюваний метод, якщо його безпека підтверджена для конкретної функції.

Кожен критичний модуль повинен, де практично можливо, мати:

1. normal mode;
2. islanded/local mode;
3. low-power або manual mode;
4. substitute-material path;
5. нижчий технологічний fallback;
6. критерій, за яким система чесно визнає: «ця функція більше не може бути гарантована».

Мета — не підтримувати однаковий комфорт на всіх рівнях, а **не втрачати життєво важливу функцію раптово через одну відсутню деталь**.

## 35.28. Dependency-complete device standard {#s34-047}

Критичний VSS-пристрій вважається описаним не тоді, коли є лише BOM і схема складання, а коли існує dependency-complete package. Він включає:

- функцію та вимірюваний acceptance test;
- вхідні матеріали та допустимі заміни;
- потрібні інструменти й калібри;
- компетенції та мінімальний рівень навчання;
- енергетичні потреби;
- витратні матеріали й строк ресурсу;
- ремонт і типові відмови;
- небезпечні режими та заборонені імпровізації;
- upstream dependencies для кожного компонента;
- fallback-реалізації нижчих рівнів;
- процедуру незалежної реплікації.

Якщо складний компонент неможливо локально відтворити, це не приховується: він позначається як **preserve/import dependency**, а граф показує, скільки часу й запасу залишається до втрати відповідної capability.

## 35.29. Water Node як еталон багатобар'єрного VSS-модуля {#s34-048}

Водний модуль є показовим прикладом принципу «не одна магічна технологія, а кілька незалежних бар'єрів». Його конкретна реалізація може включати грубе відділення сміття, тонку фільтрацію, сорбцію, мембранний або іонообмінний бар'єр, окрему стадію знезараження, чистий резервуар і контроль процесу.

VSS не має права називати невідому воду «безпечною» лише тому, що вона прозора, пройшла через вугілля, мідь, UV або інший один метод. Для кожного заявленого класу забруднення потрібен валідований бар'єр і тестовий критерій.

Цей принцип одночасно робить пристрій модульним і придатним до деградації: високі рівні можуть використовувати мембрани, сенсори й автоматику; нижчі — простіші перевірені методи, при цьому інтерфейс повинен чітко показувати, **які класи ризику залишилися непокритими**.

-----

-----

# 36. Vilnism Civilization OS: інфраструктура, а не власна імперія (новий розділ, додано у v0.8)

Vilnism не має потреби володіти містами, землею або політично підпорядковувати собі партнерські громади. Його наймасштабніша роль — **інфраструктурний протокол**, який дозволяє незалежним людям і громадам знаходити одне одного, документувати досвід, створювати forks, будувати проєкти, обмінюватися ресурсами й перевіряти рішення.

## 36.1. Архітектурні шари {#s35-001}

Civilization OS може складатися з взаємозамінних і федеративних шарів:

1. **Canon / Foundation** — цінності, права, моделі, гіпотези й стандарти.
2. **Canon Studio** — versioning, forks, proposals, evidence, source maps і reproducible releases.
3. **Civilization Wiki** — практичне знання, де стаття веде до креслень, BOM, коду, тестів, залежностей і реальних інсталяцій.
4. **Science Commons** — challenges, hypotheses, prototypes, peer review, replication і open research.
5. **Settlement Network** — verified profiles людей, громад, організацій, підприємств і проєктів.
6. **Civilization Graph** — зв’язки між компетенціями, ресурсами, технологіями, проблемами, моделями й результатами.
7. **Project / Capital / Talent Marketplace** — matching ресурсів без перетворення платформи на центрального власника.
8. **Intercommunity Protocol** — договори, мобільність, settlement, asset portability і взаємодопомога.
9. **AI orchestration layer** — навігація, дедуплікація, переклад, synthesis і пошук, але без прихованого суверенітету.

## 36.2. Federation first {#s35-002}

Будь-який критичний сервіс має проєктуватися так, щоб громада могла self-host, export, mirror або замінити implementation. Протокол важливіший за конкретний сервер. Відкриті API, open formats і portable identity не дозволяють перетворити Civilization OS на єдину точку контролю.

## 36.3. Стандарт сильніший за монополію {#s35-003}

Мета — не юридично закріпити монополію Vilnism, а створити стандарт, який добровільно використовується через корисність, сумісність і network effects. Конкурент завжди має право створити кращу реалізацію або fork протоколу.

-----

-----

# 37. Constructive Competition і Civilization Evolution Loop (новий розділ, додано у v0.8)

## 37.1. Базовий цикл {#s36-001}

> **Problem → Proposal → Prototype → Test → Independent Replication → Adoption → Standard → New Criticism.**

Цей цикл застосовується не лише до hardware і science, а й до governance, освіти, економіки, архітектури, конфліктів, логістики й організації праці — там, де експеримент добровільний, етичний і не порушує базових прав.

## 37.2. Політика не зникає повністю {#s36-002}

Конфлікт інтересів неможливо усунути декларацією. Vilnism прагне мінімізувати **боротьбу за єдиний центр влади**, а не заперечувати існування розбіжностей. Коли можливі кілька сумісних добровільних моделей, право на fork, exit і parallel trial має перевагу над примусовим уніфікуванням.

## 37.3. Метрики не стають новою владою {#s36-003}

Результат не повинен стискатися в один “правильний” score. Система показує trade-offs: модель може бути дешевшою, але менш приватною; стійкішою, але менш гнучкою; продуктивнішою, але вимагати більше часу. Рішення залишається за добровільними учасниками.

## 37.4. Негативний результат — внесок {#s36-004}

Документована невдача, що дозволяє іншим не повторити дорогу помилку, є цивілізаційним внеском. Платформа повинна зберігати failure reports не менш ретельно, ніж успіхи.

-----

-----

# 38. Science Commons і Social Knowledge Compiler (новий розділ, додано у v0.8)

## 38.1. Від стрічки до накопичуваного знання

Соціальна мережа Civilization OS не повинна винагороджувати нескінченний scroll, outrage або саму популярність. Її базові об’єкти — Problem, Question, Proposal, Evidence, Prototype, Experiment, Replication, Failure, Standard, Project і Request.

## 38.2. Social Knowledge Compiler

Дискусія має мати шлях до структурованого результату. AI і людські редактори можуть:

- знаходити дублікати і попередні спроби;
- будувати argument maps;
- відділяти факт, припущення, норму й метафору;
- формувати RFC і test plan;
- пов’язувати дискусію з hardware/software repositories;
- відстежувати незалежні replication attempts;
- створювати living summaries замість втрати знання у хронологічній стрічці.

## 38.3. Challenge System

Громади й люди можуть публікувати чіткі цивілізаційні задачі з constraints і метриками: вода, енергія, житло, ремонтопридатність, харчування, медицина, навчання, governance тощо. Відкритий challenge не передбачає, що рішення вже відоме.

## 38.4. Open engineering package

Для фізичного рішення стандартний пакет за можливості включає: purpose, assumptions, CAD, BOM, firmware/source, materials, tools, assembly, maintenance, safety, cost, test data, known failures, substitutions, provenance і replication history.

## 38.5. Forum як Human R&D Layer

Форум є не лише місцем дискусії. Для Civilization Graph він працює як **людський R&D layer**, у якому кожний технологічний gap може бути перетворений на перевірювану роботу.

Прив'язка повинна бути машинозчитуваною:

**Graph Node / Knowledge Gap ↔ Topic ↔ Proposal ↔ Prototype ↔ Test ↔ Replication ↔ Evidence Package ↔ Status.**

Тема не вважається завершеною через consensus. Її технічний результат переходить у вищий evidence state лише після виконання заявленого acceptance test та, для критичних технологій, незалежної реплікації.

## 38.6. Bounties, crowdfunding і Civilization Research Campaigns

Knowledge Gap може мати bounty або окремий відкритий збір на CAD, матеріали, лабораторний аналіз, польовий тест чи незалежну реплікацію. Фінансування не купує істинність результату: джерело грошей, конфлікти інтересів і критерії приймання публікуються разом із evidence.

Першою великою публічною кампанією може бути **Build Civilization Game**: спільнота фінансує й одночасно наповнює реальними даними технологічне дерево, на якому потім працює гра і simulation engine.

-----

-----

# 39. Репутація, ідентичність і захист від соціального кредиту (новий розділ, додано у v0.8)

## 39.1. Немає єдиного бала людини {#s38-001}

Vilnism відкидає універсальний рейтинг моральної цінності людини. Не допускається агрегований score, який одночасно змішує поведінку, політичні погляди, здоров’я, особисте життя, кредит, освіту й соціальну популярність та визначає базові права.

## 39.2. Контекстна доказова репутація {#s38-002}

Допустимі окремі task-specific сигнали: завершені контракти, verified skills, peer review, replicated contributions, safety record, project delivery, dispute history із апеляціями. Система повинна показувати джерело, контекст, давність, uncertainty і право на виправлення.

## 39.3. Idea evaluation ≠ executor trust {#s38-003}

Наукова гіпотеза оцінюється без статусу автора. Але людина, яка просить $500 000, обладнання чи команду, може бути оцінена за історією виконання аналогічних зобов’язань. Це різні задачі, які не можна змішувати.

## 39.4. Privacy by community choice within rights floor {#s38-004}

Громади можуть мати різні режими внутрішньої прозорості, але не можуть робити відмову від фундаментальної приватності умовою людської гідності або базових прав. Selective disclosure має перевагу над тотальним профілюванням.

-----

-----

# 40. Intercommunity Protocol, мобільність і міжкомунальна економіка (новий розділ, додано у v0.8)

## 40.1. Громади як автономні економічні вузли {#s39-001}

Кожна громада зберігає власну модель власності, governance і локального обліку. Intercommunity Protocol визначає не “правильну економіку”, а сумісні способи взаємодії між різними системами.

## 40.2. Стандартні договори {#s39-002}

Реєстр може включати versioned open templates для:

- labor mobility;
- mutual residency;
- trade;
- education exchange;
- medical assistance;
- disaster mutual aid;
- technology sharing;
- research partnership;
- joint ventures;
- resource-sharing;
- project financing;
- dispute resolution.

## 40.3. Мобільність людини {#s39-003}

Людина завжди є стороною власного переходу. Community не може “передати” людину іншій community як актив. Home і host community можуть укладати тристоронні угоди про житло, страхування, навчання, сімейну підтримку, компенсацію реальних витрат і повернення, але праця людини лишається добровільною.

## 40.4. Portable Community Account {#s39-004}

Стандартизований облік може переносити або засвідчувати права людини: housing equity, cooperative capital, частки підприємств, накопичені резерви й інші договірні активи. Базові режими: leave in place, liquidate, transfer/exchange — за правилами відповідних громад і чинного права.

## 40.5. Міжкомунальні підприємства {#s39-005}

Кілька громад можуть створювати joint ventures, виробничі ланцюги й дослідницькі програми. Людина, яка стала співзасновником проєкту, не втрачає свою частку лише через повернення до іншої community; custody або передача community можлива тільки за окремою добровільною угодою.

## 40.6. Multi-asset accounting {#s39-006}

Мережа не вимагає єдиної наддержавної валюти. Вона може обліковувати fiat, crypto, local units, equity, матеріальні ресурси, energy units та інші активи через явні conversion rules і provenance. Технологічна сумісність не дорівнює монетарному суверенітету платформи.

-----

-----

# 41. Settlement Network, Civilization Graph і довгострокова безперервність (новий розділ, додано у v0.8)

## 41.1. Глобальна мережа поселень

Vilnism має спочатку підключати реальні існуючі communities, а не вимагати, щоб вони стали “містами Vilnism”. Verified community profile може містити governance, land model, population, infrastructure, projects, needs, failures, technologies, research і канали співпраці, які сама community погодилася публікувати.

## 41.2. Партнерська позиція

Перший контакт із практиками має виходити з асиметрії досвіду: у них є реальні роки експлуатації, у Vilnism — інструмент систематизації. Платформа просить critical review і operational evidence, а натомість повертає structured knowledge, comparisons, open tools і доступ до ширшої мережі. Союз означає інфраструктурну кооперацію, а не підпорядкування Canon.

## 41.3. Civilization Graph

Граф пов’язує:

- person ↔ competence;
- person ↔ community;
- community ↔ resource / need;
- project ↔ team / capital / equipment;
- technology ↔ dependencies / installations / failures;
- governance model ↔ evidence / scale / outcomes;
- problem ↔ prior attempts / experts / active experiments.

Це дозволяє AI виконувати matching без перетворення графа на центральний social score.

## 41.4. Civilization Reproducibility Index

Замість одного числа використовується profile/tree: water, shelter, food, sanitation, energy, medicine, communications, fabrication, chemistry, electronics, computing, machine tools, transport, governance, education та інші layers. Для кожного вимірюється доступне knowledge, tools, local capability, dependencies, repairability і recovery time.

## 41.5. Civilization Backup

Довгострокова мета — не просто архів текстів, а dependency-complete карта від базових ресурсів і простих інструментів до складної промислової цивілізації, з можливістю offline reproduction. VSS/VCRP є нижніми щаблями цієї системи.

## 41.6. Civilization memory

Через десятиліття й століття найбільшою цінністю мережі може стати пам’ять причин, рішень і наслідків тисяч суспільних та технологічних експериментів. Нове покоління не повинно починати з нуля.

## 41.7. Кінцева мета

> **Vilnism має збільшувати здатність цивілізації до самоорганізації, накопичення знань, експериментування, відтворення технологій, мирного розходження моделей і добровільної кооперації між незалежними спільнотами.**

Успіх означає не те, що через тисячу років усі живуть за текстом XXI століття, а те, що механізм безперервного вдосконалення, forkability і цивілізаційної пам’яті пережив сам початковий Canon.

-----

## 41.8. Executable Civilization Graph

Civilization Graph стає не лише картою знань, а **виконуваною моделлю залежностей**. Мінімальні типи вузлів:

- `Resource` — матеріал, вода, земля, паливо, запас;
- `Skill` — компетенція людини або команди;
- `Tool` — інструмент, верстат, калібр;
- `Process` — технологічний або організаційний процес;
- `Component` — стандартний вузол;
- `Device` — функціональний пристрій;
- `Infrastructure` — водна, енергетична, транспортна, цифрова та інша система;
- `KnowledgePackage` — інструкція, стандарт, CAD, доказ реплікації;
- `Capability` — здатність громади гарантовано виконувати функцію;
- `FallbackPath` — нижчий або альтернативний шлях;
- `KnowledgeGap` — відсутня або неперевірена ланка.

Ребра графа описують `requires`, `consumes`, `produces`, `repairs`, `maintains`, `substitutes`, `teaches`, `measures`, `verifies`, `depends_on` і `falls_back_to`.

## 41.9. Real Mode: цифровий двійник реальної спроможності

Поселення може накласти на загальний граф власний стан: фактичні запаси, справні верстати, доступну потужність, воду, людей і їхні компетенції, резервні деталі, строки ресурсу та зовнішні залежності.

Тоді tech tree підсвічує не абстрактно «винайдені» технології, а:

- що реально доступне зараз;
- що доступне лише завдяки запасам;
- що може бути виготовлене локально;
- що залежить від імпорту;
- де є single point of failure;
- який максимальний fallback-рівень зберігає критичну функцію.

## 41.10. Reality ↔ Simulation Loop

Civilization Simulation Game і реальний Civilization OS використовують спільну схему Technology Graph. Реальний стан можна копіювати в simulation sandbox, не змінюючи реальні ресурси.

Сценарії можуть моделювати втрату електрики, імпорту, конкретного спеціаліста, водного джерела, транспортного вузла, матеріалу або виробничої лінії. Результатом симуляції є не наказ, а список пояснюваних вразливостей, альтернатив та експериментів.

Цикл:

**real state → simulation snapshot → stress scenarios → failure paths → proposed remediation → physical test → evidence → updated graph**.

Модель або AI не отримує права автоматично перетворювати прогноз на обов'язкове рішення.

## 41.11. Knowledge Gap як видимий стан цивілізації

Якщо система знає, що технологія існує, але не має перевіреного dependency-complete шляху її відтворення, це не маскується під «knowledge available». Створюється `KnowledgeGap` з рівнем критичності, причиною, потрібними експериментами, зовнішніми джерелами та статусом незалежної реплікації.

Глобальним квестом Civilization OS стає поступове скорочення таких gaps: **описати цивілізацію настільки добре, щоб її критичні функції можна було відновити з відомих нижчих рівнів або чесно знати, де це поки неможливо**.


## 41.12. Technology Node lifecycle

Кожний вузол Technology Graph окремо зберігає **reproducibility status** і **epistemic status**.

Reproducibility lifecycle:

`OPEN_GAP → PROPOSED → DOCUMENTED → PROTOTYPED → LAB_TESTED → FIELD_TESTED → INDEPENDENTLY_REPLICATED → VERIFIED`.

Epistemic layer для майбутніх технологій:

- `VERIFIED_REAL` — реально відтворено з достатнім evidence;
- `ENGINEERING_KNOWN` — технологія відома й використовується, але dependency-complete Civilization OS package ще неповний;
- `RESEARCH` — є experimental evidence, але технологія не є зрілою;
- `THEORETICAL` — модель узгоджується з відомою наукою, але практичної реалізації немає;
- `SPECULATIVE` — гіпотеза з великою невизначеністю;
- `FICTIONAL` — художня механіка, яка не подається як факт.

Так гра може дивитися далеко в майбутнє, не стираючи межу між перевіреним знанням і уявою.

## 41.13. Game as distributed civilization research

Civilization Simulation Game використовує перевірену частину графа як reality anchor, а frontier layers — як простір сценаріїв. Людські партії можуть, за явної згоди й із захистом приватності, зберігатися як simulation traces.

AI може знаходити незвичайні стратегії, які стабільно переживають stress scenarios, і створювати з них `ResearchCandidate`. Такий candidate повертається на Forum/Labs і не переходить у реальний стандарт, доки не пройде окрему перевірку.

## 41.14. Distributed Simulation Compute

Великі simulation batches природно shard-яться на незалежні jobs. TOS може виконувати їх:

- локально;
- на вузлах тієї самої людини/організації через Private Grid;
- на settlement cluster;
- через майбутній добровільний Global Compute Exchange.

Результат із недовіреного community compute повинен мати deterministic seed/model version, execution receipt і verification policy. Критичні секрети, приватні персональні дані та irreversible financial/security execution не передаються на довільні community nodes.

## 41.15. Єдиний цикл розвитку

Довгостроковий цикл Civilization OS:

**Forum → Research → Prototype → Physical Test → Verified Graph → Simulation → Game / Headless Runs → Human & AI Strategies → Settlement Trial → Telemetry → Evidence → Updated Graph.**

Таким чином Forum, гра, TOS і реальні поселення не є незалежними продуктами. Вони є різними поверхнями одного процесу накопичення цивілізаційного знання.

-----

# 42. Міжпоколінна безперервність і друге покоління

## 42.1. Перше і друге покоління мають різні функції {#s41-001}

Перше покоління засновників перевіряє, чи працюють принципи та інфраструктура в реальному житті. Друге покоління, яке виросло всередині добровільних communities, перевіряє значно складніше питання: **чи здатна система створити стійку культуру без перетворення Canon на догму.**

Люди, що створюють перші communities, неминуче несуть моделі попереднього суспільства. Для дітей, які виростають у новому середовищі, відкриті знання, право на вихід, практична освіта, local governance, міжкомунальна мобільність і право на fork можуть стати звичайною інфраструктурою, а не політичним експериментом.

## 42.2. Успадковувати метод, а не догму {#s41-002}

Найбільший ризик другого покоління — інституційна індоктринація: «Canon правильний, тому що так сказали засновники». Це прямо суперечить Vilnism.

Дитина повинна мати доступ до:

- причин появи кожного фундаментального правила;
- джерел, доказів і контраргументів;
- історії змін і провалів;
- альтернативних моделей та forks;
- unresolved questions;
- процедур зміни або відмови від Canon.

> **Між поколіннями передається не обов'язок вірити в Canon, а здатність перевіряти й покращувати системи.**

## 42.3. Intergenerational Continuity Test {#s41-003}

Система проходить сильний тест лише тоді, коли покоління, яке не брало участі в її заснуванні, має реальну можливість її залишити або змінити — і все одно добровільно вважає значну частину принципів корисними.

Негативними сигналами є:

- соціальне покарання за критику Canon;
- залежність доступу до базових прав від ідеологічної лояльності;
- заборона дітям знайомитися з альтернативними системами;
- культ засновників;
- приховування історії помилок;
- спадкова політична або економічна каста.

## 42.4. Цивілізаційна ідентичність без єдиної держави {#s41-004}

Якщо молоді люди можуть навчатися в community A, працювати в B, створювати проєкт із C і D та заснувати E, виникає міжкомунальна ідентичність, заснована не на одному паспорті або одному уряді, а на сумісних протоколах, мобільності, knowledge commons та практиці добровільної кооперації.

Це не вимагає однакового Canon. Сумісність може існувати між різними forks.

-----

-----

# 43. Historical & Mythological Governance Patterns

## 43.1. Минуле як бібліотека гіпотез, а не джерело догми {#s42-001}

Vilnism може вивчати стародавні держави, конфедерації, релігійні тексти, міфи й легенди, але з обов'язковим розділенням рівнів доказовості:

- `[HIST]` — історично підтверджена практика;
- `[TEXT]` — модель, що прямо міститься у давньому тексті;
- `[MYTH]` — міфологічний/легендарний сюжет;
- `[MAP]` — історична картографічна назва;
- `[SPEC]` — сучасна реконструкція або гіпотеза.

Міфологічний сюжет може породити корисний governance pattern, але не стає історичним фактом.

## 43.2. Vajji і gana-sangha {#s42-002}

Давньоіндійські gana-sangha та текстова традиція про Vajji показують цінність регулярних зборів, процедурної пам'яті, координації та внутрішньої довіри. Для Civilization OS це підсилює принцип: **мережеву цивілізацію можна зруйнувати не лише матеріально, а й розривом довіри та процедурної сумісності між вузлами.**

## 43.3. Task-specific assemblies {#s42-003}

Згадки про sabha/samiti та структуровані ради в *Arthaśāstra* підтримують гіпотезу, що різні задачі потребують різних форм governance. Science, rights, resources, emergency response та local matters не повинні автоматично проходити через один універсальний орган.

## 43.4. Атлантида Платона як текстовий федеративний архетип {#s42-004}

Атлантида в *Critias* не приймається як археологічно підтверджена держава. Однак опис десяти локальних центрів, спільних правил, періодичних зборів, взаємної допомоги, обмеження внутрішньої війни й арбітражу є корисним `[TEXT][MYTH]`-патерном для Intercommunity Protocol.

## 43.5. Prosperity Corruption Watch {#s42-005}

Платонівський мотив деградації після матеріального успіху підтримує окремий клас метрик: concentration of power, ownership concentration, exit barriers, status capture, dependency asymmetry та перетворення престижу внеску на престиж демонстративного багатства.

Матеріальне процвітання не повинно автоматично прирівнюватися до цивілізаційного успіху.

## 43.6. Civilization Backup після втрати технологічного рівня {#s42-006}

Мотив зникнення письма й складних знань після катастроф підсилює VSS/VCRP: backup має бути доступний шарами — від піктограм і survival до ремесел, металургії, машинобудування, електроніки, напівпровідників та інших high-dependency systems.

Кожний рівень повинен навчати не лише користуватися технологією, а й відтворити інструменти для наступного рівня.

## 43.7. Tartary і правило епістемічної стриманості {#s42-007}

Історичні назви *Tartary / Great Tartary* на картах трактуються передусім як широкі географічні категорії й не є самі по собі доказом єдиної прихованої держави. Для Vilnism цікаві реальні конфедеративні й поліцентричні моделі Внутрішньої Азії, але вони мають аналізуватися окремо від пізніх альтернативно-історичних реконструкцій.

## 43.8. Historical Pattern Pipeline {#s42-008}

Будь-який стародавній або міфологічний мотив проходить один шлях:

**source → evidence class → pattern → modern hypothesis → pilot/test → evidence → optional standard.**

> **Минуле не дає готової Конституції. Воно розширює простір рішень, які сучасна Civilization OS здатна перевірити.**

Детальна дослідницька версія винесена в `VILNISM_HISTORICAL_MYTHOLOGICAL_GOVERNANCE_PATTERNS_v0.1_uk.md`.

-----

-----

# 44. Climate & Catastrophe Resilience Doctrine

## 44.1. All-hazards замість одного апокаліптичного сценарію {#s43-001}

Civilization OS не повинна оптимізуватися під одну конкретну катастрофу. Реальний ризик — це **compound failure**, коли кілька подій накладаються: спека + посуха + пожежа; повінь + забруднення води + епідемія; землетрус + пожежа + втрата електрики; війна + логістичний шок + дефіцит добрив; геомагнітна буря + збій зв'язку + зупинка частини енергетики.

Канон тому використовує **all-hazards architecture**: критичні функції проєктуються так, щоб відмова одного зовнішнього контуру не руйнувала всю систему.

## 44.2. Settlement Habitability Envelope {#s43-002}

Кожна громада повинна мати версіонований профіль фізичної придатності місця. Мінімальні осі:

- довгострокова температура і тепловий стрес;
- доступна вода, drought reserve і ризик salinization;
- flood / flash-flood / storm-surge exposure;
- wildfire і smoke exposure;
- wind / cyclone / tornado exposure;
- landslide / erosion / subsidence;
- earthquake / liquefaction;
- tsunami для прибережних зон;
- volcanic ash / lahar exposure, якщо релевантно;
- air quality;
- crop suitability і зміна сезонності;
- наявність безпечних evacuation routes;
- зовнішні залежності, які можуть зникнути одночасно.

Метою є не рейтинг «безпечне/небезпечне», а **design envelope**: у яких межах місце залишається життєздатним і які тригери переводять його в режим адаптації, тимчасової евакуації або managed retreat.

## 44.3. Climate adaptation is infrastructure {#s43-003}

Кліматична адаптація не є окремою екологічною програмою. Вона входить у базове проєктування:

- пасивне охолодження і теплові refuges;
- тінь, вентиляція, зелена інфраструктура;
- резервні джерела води і повторне використання води;
- floodable / sacrificial zones там, де це доречно;
- пожежостійкі матеріали й контроль рослинності біля критичних об'єктів;
- локальне зберігання води та продуктів;
- кліматично різноманітні культури;
- резервні indoor/protected growing systems;
- мікромережі, які можуть працювати islanded;
- розміщення критичних активів поза одним hazard zone.

## 44.4. Managed Retreat Protocol {#s43-004}

Канон не повинен створювати культ «залишатися будь-якою ціною». Якщо місце системно виходить за межі Habitability Envelope, громада повинна мати заздалегідь визначений механізм:

**observe → adapt → partial relocation → asset transfer → full retreat.**

Тригери мають бути вимірюваними: багаторічна втрата водного балансу, повторюване затоплення, неприйнятний heat exposure, постійна salinization, неприйнятний wildfire corridor або інша фізична втрата придатності.

Право на вихід поширюється і на **вихід із території**.

## 44.5. Географічна диверсифікація {#s43-005}

Жодна велика мережа Vilnism не повинна зберігати критичні knowledge, seeds, cryptographic recovery material, tooling або виробничу компетенцію лише в одному регіоні.

Використовується принцип **N-region continuity**: критична функція має незалежні копії у географічно віддалених hazard domains.

-----

-----

# 45. Extreme Settlement Resilience Standard

## 45.1. Критичні функції {#s44-001}

Поселення вважається стійким не за наявністю окремих пристроїв, а за здатністю підтримувати функції:

1. вода;
2. санітарія;
3. харчування;
4. укриття і thermal safety;
5. базова медицина;
6. енергія;
7. зв'язок та інформація;
8. пожежна і аварійно-рятувальна здатність;
9. логістика і ремонт;
10. governance continuity;
11. психосоціальна стабільність;
12. відтворення ключових навичок і знань.

## 45.2. Water Continuity {#s44-002}

Вода повинна мати щонайменше кілька **фізично незалежних шляхів**: основне джерело, резерв, накопичення та emergency purification.

Планування включає:

- drought budget;
- flood contamination;
- salt intrusion для прибережних/низинних зон;
- microbial contamination;
- можливість ручної подачі при відмові насосів;
- запас витратних матеріалів і методи, що не залежать від одного специфічного фільтра;
- окреме аварійне водопостачання медичного пункту.

## 45.3. Food Continuity {#s44-003}

Калорійна безпека не може залежати від одного crop, одного сезону, одного seed supplier або одного типу добрив.

Мінімальний food-resilience stack:

- кілька груп основних культур;
- locally reproducible seed;
- дубльовані seed stores;
- локальна насіннєва селекція й обмін між громадами;
- crop rotation і soil-fertility loop;
- запас стабільних продуктів;
- preservation: drying, fermentation, canning/freezing там, де доступна енергія;
- protected cultivation;
- резерв культур, придатних для низьких input;
- план animal-feed continuity, якщо громада залежить від тваринництва;
- харчовий contingency plan для неврожаю кількох сезонів.

## 45.4. Energy Black Start {#s44-004}

Microgrid має бути здатна відновлюватися після повного blackout без зовнішньої мережі.

Критичні навантаження відокремлюються від comfort loads. Потрібні:

- black-start procedure;
- локальні manual overrides;
- запас ключових controllers/fuses/contactors;
- резерв низьковольтного живлення;
- можливість забезпечити воду, медицину, зв'язок і мінімальне освітлення навіть при тривалому дефіциті енергії;
- recovery drills.

## 45.5. Heat, cold, smoke and air {#s44-005}

Поселення повинно мати **thermal refuges**, які можуть підтримувати безпечний діапазон навіть коли основні будинки тимчасово непридатні.

Для smoke/ash/air pollution передбачаються:

- clean-air rooms;
- фільтрація, яку можна обслуговувати локально;
- запас респіраторного захисту для критичного персоналу;
- мінімізація outdoor work у небезпечні періоди;
- окремий захист медичного пункту.

## 45.6. Flood, storm, wildfire and geohazard zoning {#s44-006}

Критична інфраструктура не повинна концентруватися в одному floodplain, fire corridor або іншому hazard pocket.

Для кожного поселення створюється локальна карта:

- no-build;
- critical-infrastructure;
- shelter;
- evacuation;
- water;
- fuel;
- medical;
- assembly;
- fallback zones.

## 45.7. Health emergency capability {#s44-007}

Громада повинна мати не лише аптечку, а **health emergency architecture**:

- syndromic/community surveillance з мінімізацією персональних даних;
- окремі isolation spaces;
- scalable clinical area;
- WASH і infection-control procedures;
- rotating essential medicine stock;
- cold-chain fallback для препаратів, що її потребують;
- PPE і локально відтворювані бар'єрні засоби;
- dead-body management і dignified documentation для mass-casualty scenarios;
- mental-health and grief support;
- mutual-aid agreements із зовнішніми медичними вузлами.

## 45.8. Radiological, chemical and severe contamination events {#s44-008}

Кожна громада повинна мати базовий **detect–shelter–isolate–decontaminate–evacuate** framework для небезпечного забруднення.

Канон не вимагає перетворювати поселення на військовий об'єкт. Він вимагає:

- знати типи локальних industrial/agricultural hazards;
- мати засоби моніторингу, де це виправдано;
- мати clean/dirty zoning;
- захищати воду й вентиляцію;
- мати процедури тимчасового shelter-in-place;
- мати маршрут евакуації й зовнішні канали лабораторної перевірки.

## 45.9. Space weather and electronics resilience {#s44-009}

Геомагнітні бурі можуть порушувати grid, GNSS, radio і satellite-linked services. Тому settlement operations не повинні припускати безперервну доступність GPS, супутникового часу чи зовнішньої електромережі.

Потрібні:

- локальні карти й не-GNSS навігація;
- offline timekeeping;
- автономні radio procedures;
- локальні енергетичні island modes;
- spare critical electronics;
- перевірені процедури безпечного shutdown/restart для чутливої інфраструктури.

## 45.10. Knowledge and skill redundancy {#s44-010}

Критична компетенція не повинна належати одній людині.

Для кожної функції визначається:

- primary specialist;
- minimum two cross-trained backups;
- offline SOP;
- training drill;
- список інструментів і consumables;
- competency expiry / retraining interval.

## 45.11. Population continuity and succession {#s44-011}

Сценарій повинен враховувати втрату частини ключових людей. Governance, medicine, water, energy, food, communications і records повинні мати succession trees без створення постійної надзвичайної еліти.

## 45.12. Mutual aid over autarky {#s44-012}

Повна самодостатність кожного settlement — не обов'язкова і часто неефективна. Мета — **local survival + network recovery**.

Громади укладають mutual-aid contracts для:

- медичної евакуації;
- seed replacement;
- specialist exchange;
- temporary relocation;
- spare parts;
- data recovery;
- emergency food/water support.

## 45.13. Extreme Resilience Certification {#s44-013}

Стійкість перевіряється не декларацією, а drills:

- 72 години без зовнішньої електрики;
- 7–30 діб degraded communications;
- water-source loss;
- crop failure;
- heat/smoke shelter;
- evacuation;
- medical surge;
- loss of key operator;
- corruption of local digital records;
- simultaneous compound scenario.

Результатом є не «pass forever», а versioned resilience profile з відкритими gaps і remediation plan.

-----

-----

# 46. Scenario Layer: hard civilizational bifurcation

Vilnism може зберігати жорсткі футурологічні сценарії як **stress-test corpus**, але не як канонічне передбачення.

Документ `velyke_perezavantazhennia_dvosharova_tsyvilizatsiia_hard_scenario.md` класифікується як `[SCENARIO][SPEC]`: він моделює каскад фінансової, військової, логістичної, продовольчої, цифрової та демографічної кризи й поділ на System / Divergent / Wild Zones.

Його функція в Civilization OS:

- знаходити залежності, які Canon недооцінив;
- створювати red-team exercises;
- перевіряти VSS/VCRP та Extreme Resilience Standard;
- тестувати governance під довготривалим compound stress;
- відділяти сценарне моделювання від тверджень про неминучість конкретних подій.

Кліматичні зміни й природні катастрофи додаються до цієї моделі як **незалежний множник ризику**, а не як обов'язкова причина політичного сценарію.

-----

# 47. Pacifism, Self-Preservation & Conflict Retreat Doctrine

## 47.1. Мирний характер системи {#s46-001}

Vilnism є мирною цивілізаційною мережею. Війна, завоювання територій, примус і насильницьке поширення Canon не є допустимими засобами розвитку системи.

Технологічна, економічна, демографічна або організаційна перевага сама по собі ніколи не створює морального права керувати іншими людьми чи примушувати їх приймати Vilnism.

## 47.2. Життя важливіше за територію {#s46-002}

Територія, будівлі, обладнання, символи та інші матеріальні активи є замінними. Людське життя є незамінним.

Тому діє залізне правило:

> **Не обмінювати незамінне на замінне.**

Якщо евакуація, розосередження або відступ з високою ймовірністю зберігають більше життів, вони мають пріоритет над утриманням території.

Відступ у ситуації очевидної асиметрії сил не вважається моральною поразкою.

## 47.3. Право на самозбереження {#s46-003}

Пацифізм Vilnism не означає обов'язку пасивно приймати насильницьку смерть.

Коли безпосередньої загрози життю неможливо уникнути шляхом деескалації, евакуації чи відступу, люди не позбавляються права захищати життя.

Однак Canon навмисно не встановлює військової доктрини, способів ведення війни, озброєння, тактики або методів завдання шкоди. Конкретні моральні та правові рішення залишаються відповідальністю людей і громад у конкретних обставинах.

Базова послідовність:

**не починай насильство → деескалюй → уникай → евакуюй → відступай, якщо це зберігає життя → захищай життя, коли уникнення безпосередньої загрози неможливе → припиняй протистояння, щойно зникає необхідність захисту.**

## 47.4. Conflict Managed Retreat {#s46-004}

До Environmental Managed Retreat додається **Conflict Managed Retreat**.

Його мета — зберегти:

- людей;
- сімейні та соціальні зв'язки;
- критичні компетенції;
- знання та архіви;
- governance continuity;
- seed/genetic resources;
- ключові інструменти та відновлювані активи;
- здатність громади створити новий вузол.

Поселення може бути фізично залишене, але громада може продовжувати існувати як **displaced settlement** і пізніше повернутися або створити новий географічний вузол.

## 47.5. Non-Conquest Principle {#s46-005}

Vilnism не захоплює території з метою поширення Vilnism.

Право іншої громади відмовитися від Canon повинно зберігатися навіть тоді, коли Vilnism-compatible мережа має значну перевагу в ресурсах або технологіях.

Справжнім тестом добровільності системи є не її поведінка в слабкості, а її поведінка після набуття сили.

## 47.6. Civilization continuity over territorial continuity {#s46-006}

У навмисному конфлікті головним об'єктом збереження є не конкретна ділянка землі, а цивілізаційне ядро.

Тому стратегічна формула:

> **Ми не воюємо за землю, щоб зберегти систему. Ми зберігаємо людей, щоб вони могли побудувати систему знову.**

Фізична втрата одного settlement не повинна знищувати мережу. Критичні знання, управління, дані, навички та резерви повинні бути географічно розподіленими.

## 47.7. Межа Canon {#s46-007}

Цей розділ визначає етику самозбереження, евакуації, відступу, continuity та мирного характеру мережі.

Він навмисно **не переходить у military manual**. Розроблення конкретних бойових концепцій не є функцією Canon Foundation.

-----

# 48. Висновок

Вільнізм не пропонує повірити в готову модель.

Він пропонує:

- описувати принципи відкрито;
- відділяти цінності від фактів;
- перевіряти гіпотези;
- публікувати результати;
- визнавати помилки;
- зберігати історію;
- дозволяти форки;
- будувати добровільні пілоти;
- вимірювати якість життя;
- змінювати систему, якщо вона перестає служити людям.

Його сила не в обіцянці ідеального суспільства, а у створенні відкритого механізму, за допомогою якого люди можуть спільно проєктувати, перевіряти й удосконалювати способи життя.

-----

## Коротке визначення {#s47-001}

> **Вільнізм — це відкрита дослідницька платформа для проєктування, перевірки та розвитку людських спільнот, у яких головними критеріями успіху є свобода, якість життя, здоров’я, відкритість знань, добровільність і цивілізаційна стійкість.**