# Foundations of Vilnism

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

**Версія документа Foundation:** 0.15.0
**Версія корпусу / конституції:** 0.17.0
**Дата редакції:** 2026-10-30
**Статус:** авторська редакція для розгляду (`review`); прийняття конкретною громадою не засвідчено
**Формат:** Canon as Code
**Мова:** українська

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

Джерелом чинної авторської редакції є перелічені в `config/book.yml` глави. Монолітні книги, сайт, JSON, Persona Package і source map збирає Canon Studio. Історичний файл Foundation v0.13 у `canon/source/` збережено як джерело попереднього імпорту; він не підміняє поточні глави.

Нумерація успадкована: у корпусі є 48 змістових розділів із номерами 1–27 та 29–49, а також метаглава. Пропуск №28 виник під час історичного перенесення висновку; він не означає втрати поточного файла. Stable IDs та старі посилання збережено, а зміст і карта джерел відображають фактичний склад.

-----

## Журнал змін {#meta-changelog}

### Foundation 0.14 → 0.15 / corpus 0.16 → 0.17 {#meta-changelog-014-015}

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

- Уточнено ієрархію норм, процедуру набрання чинності, межі влади мейнтейнерів, незалежне оскарження та відмінність між текстовою нормою і машинним правилом.
- Посилено особистий вихід, захист дітей і залежних осіб, приватність, доступ до життєво необхідних ресурсів, ліквідність зовнішніх закупівель, добровільність внеску та прості нецифрові способи участі.
- Уточнено кризову компетентність, швидке реагування, припинення надзвичайних повноважень і збереження життєзабезпечення; додано вимоги до практичних навичок та відновлення.
- Розведено Вільнізм як добровільну філософську й суспільну модель, WebV як відкритий протокол, TOS як одну з реалізацій, Foundation як можливого координатора, DeskOS як інтерфейс та Civilization OS як прикладний шар.
- Визначено умови незалежності від центрального сервера: незалежні оператори, репліки, маршрути, ключі, локальні дані, енергія, ремонт і перевірене відновлення. Кількість облікових записів сама цього не доводить.
- Додано правила для мережевих розривів, локальних островів, відкладеної доставки, безпечного повернення зв'язку, обмежених AI-мандатів та життєвого циклу ключів. Без фізичного каналу, енергії чи копії даних гарантії зв'язку й доступності неможливі.
- Технічні деталі WebV v0.2 винесено в companion-специфікацію; реальні runtime-випробування позначено `NOT_RUN`, доки немає відповідних доказів. Символічні й філософські образи не є умовою протокольної сумісності.

### Foundation 0.13 → 0.14 / corpus 0.15 → 0.16 {#meta-changelog-013-014}

Попередня інтегрована редакція 2026-09-09 додала §49 «Web V — шлях до свободи» та дослідницький опис Web V v0.1. У заголовку метаглави тоді залишилося 0.13, хоча конфігурація пакета вже вказувала Foundation 0.14.0 і corpus 0.16.0. Цей запис відновлює простежуваність; байти історичних архівів не змінюються.

### 0.12 → 0.13 {#meta-changelog-012-013}

Версія 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 {#meta-changelog-011-012}

Версія 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 {#meta-changelog-010-011}

Додано **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 {#meta-changelog-009-010}

Версія 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 {#meta-changelog-008-009}

Версія 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 {#meta-changelog-007-008}

Версія 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 {#meta-changelog-006-007}

Версія 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 {#meta-changelog-005-006}

Версія 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 {#meta-changelog-004-005}

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

Додано:

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

### 0.3 → 0.4 {#meta-changelog-003-004}

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

Додано:

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

### 0.2 → 0.3 {#meta-changelog-002-003}

Версія 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 {#meta-changelog-001-002}

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

Додано:

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

-----

## Анотація {#meta-annotation}

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

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

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

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 там, де це практично можливо. Репутація автора не повинна визначати істинність гіпотези. Водночас історія виконання може враховуватися, коли автор просить довірити йому гроші, людей, обладнання або операційну відповідальність.

## 4.16. Права не залежать від цифрового інтерфейсу {#s04-016}

Людина зберігає базові права при втраті пристрою, ключа, зв'язку, працездатності AI або навички користування програмою. Громада, що застосовує Canon, забезпечує доступний людський і офлайн-канал звернення, підтвердження отримання та перенесення звернення до цифрового обліку без повторного стягнення плати чи втрати початкової дати. Відновлення доступу перевіряється окремо від права на невідкладну допомогу (§§14, 34).

## 4.17. Межі приєднання {#s04-017}

Користування WebV, TOS, Canon Studio, бібліотекою або ринком ресурсів саме по собі не є вступом до громади чи прийняттям її економічної моделі. Організатор повинен до приєднання відокремити правила технічної послуги, добровільний договір і конституційне членство та показати спосіб припинення кожного з них. Програмна сумісність перевіряється за відкритою специфікацією, а прийняття Canon — за §16; жодне з них не створює влади над сторонніми людьми.

-----

-----

# 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;
- інші форми, в яких ризик і винагорода описані прямо, а людина не стає заставою або власністю кредитора.

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

## 9.8. Межі канонічної економічної моделі {#s09-008}

Правило §9.7 є обов’язковим для власних добровільних договорів громади й учасників у межах прийнятої ними канонічної економічної моделі. Прихований гарантований процент не стає допустимим через назву «комісія», «частка» або «послуга»: відповідальний за договір має показати реальні витрати, розподіл ризику й умови винагороди до його укладення.

Використання WebV, TOS, відкритих стандартів або сумісного клієнта саме собою не означає прийняття цієї економічної моделі (§4.17, §16.4). Технічна сумісність не надає громаді права регулювати всі договори стороннього оператора. Учасники повинні розрізняти правила власного членства, умови конкретного обміну та правила протоколу.

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

## 9.9. Фізичний ресурс, облікова одиниця і платіжна вимога {#s09-009}

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

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

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

-----

-----

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

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

Принципи:

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

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

## 10.1. Захищені резерви та межі ризику {#s10-001}

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

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

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

## 10.2. Ліквідність зовнішнього обміну {#s10-002}

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

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

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

## 10.3. Дефіцит бюджету та невиконання зобов’язань {#s10-003}

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

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

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

-----

-----

# 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}

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

Розширений мандат має конкретний граничний строк і припиняється автоматично при першій з подій: сплив строку, підтверджене усунення підстав за наперед установленими критеріями або відкликання. Критерії враховують період стійкого відновлення, щоб один випадковий сигнал не перемикав усю систему. Продовження потребує нового обмеженого рішення з доказами необхідності; власник надзвичайного мандату не продовжує його одноосібно. Порядок передавання критичної послуги визначається §12.9.

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

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

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

Для представницьких і наглядових ролей жереб може формувати пул добровільних кандидатів, які пройшли мінімальну підготовку для цієї ролі; група перевіряє готовність і конфлікти інтересів та визначає представника й дублера. Людина може відмовитися без втрати прав. Жереб не призначає лікаря, оператора небезпечного обладнання чи керівника рятувальної операції без відповідної компетентності. Оперативні функції виконують заздалегідь підготовлені команди за §§12.6–12.8; громадський нагляд залишається незалежним.

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

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

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

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

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

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

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

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

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

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

Після пілоту сторони можуть переглянути стратегії з урахуванням доказів. Перевага однієї моделі не надає її автору влади примусово приєднати іншу групу. Розділення не є універсально можливим рішенням: для спільної води, екологічних наслідків та іншої неподільної інфраструктури діють §§31–32.

## 12.8. Завчасний оперативний мандат {#s12-008}

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

## 12.9. Завершення надзвичайних повноважень і безперервність послуги {#s12-009}

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

-----

-----

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

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

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

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

- Усередині громади оператор публікує агреговані ресурси й підзвітні рішення; персональні відомості відкриваються лише для визначеної мети з мінімальним необхідним доступом (§30.8).
- Партнери отримують погоджений обсяг даних у межах конкретного договору й повноваження; цей договір не передає автоматично права на дані сторонніх людей.
- Для зовнішніх учасників зберігається доступ до публічних правил. Незнайомість, незгода або технічна сумісність з іншою мережею не є доказом ворожості.

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

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

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

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

AI може допомагати готувати оцінку лише у межах §20. Його неупередженість не припускається: модель і дані можуть помилятися, а прогноз не створює мандату. Відповідальне людське рішення та незалежний перегляд визначаються §§12 і 14; розвиток системи насильницьким поширенням Canon заборонений (§47).

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

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

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

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

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

Оперативні деталі можуть тимчасово захищатися відповідно до §13.1. Секретність конкретної вразливості не скасовує незалежний контроль і не дозволяє заднім числом змінити публічну підставу рішення.

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

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

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

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

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

-----

-----

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

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

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

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

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

## 14.1. Доступна незалежна апеляція {#s14-001}

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

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

## 14.2. Рішення, яке можна виконати {#s14-002}

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

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

## 14.3. Терміновий захист і вразливі учасники {#s14-003}

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

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

-----

-----

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

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

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

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

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

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

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

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

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

Редакційний розгляд, технічне злиття, перевірка релізу та прийняття норми розділяються. Істотну зміну перевіряє особа або команда, незалежна від автора; мейнтейнер виконує погоджені критерії й мотивує відмову. Кілька підписів не доводять незалежності, якщо всі ключі контролює одна сторона. Жодна технічна роль не створює конституційної чинності поза §16.6.

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

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

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

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

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

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

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

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

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

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

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

-----

-----

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

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

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

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

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

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

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

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

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

## 16.4. Ієрархія документів і межі нормативної дії {#s16-004}

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

У межах прийнятого Canon діє така ієрархія:

1. Базові права й обмеження примусу (§§4, 16.1, 29.17, 30.14) становлять мінімальний захист людини; нижчий документ не може його скасувати.
2. Прийняті конституційні норми визначають компетенції, спосіб прийняття рішень і захист прав.
3. Локальні регламенти та конкретні мандати реалізують лише явно надані повноваження й мають визначену сферу, строк та перегляд.
4. Технічні стандарти, інструкції, програмний код і пояснювальні матеріали виконують та пояснюють норми; нових повноважень вони не створюють.

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

## 16.5. Мінімальний паспорт норми {#s16-005}

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

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

## 16.6. Створення, публікація, прийняття й чинність {#s16-006}

Стани документа зберігаються окремо: **пропозиція / авторська редакція → опублікований текст → прийнятий визначеною спільнотою текст → чинна для неї норма**. Можливі також відхилення, відкликання пропозиції, зупинення або заміна чинної норми. Наявність файла, merge, тег, підпис, перевірений хеш чи публікація на сайті не виконує жодного переходу від імені громади.

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

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

## 16.7. Зміни ядра, пілоти й захист від зворотної дії {#s16-007}

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

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

Нові санкції та обов'язки не застосовуються до минулої поведінки шляхом непомітної заміни версії. Виправлення помилки обліку або відновлення порушеного права має окрему підставу й журнал. Терміновий захисний захід діє лише в межах §§12 і 14 та не переписує конституцію.

## 16.8. Статус цієї редакції {#s16-008}

Доповнення Canon corpus v0.17.0 / Foundation v0.15.0 є авторською редакцією для перевірки й обговорення (`review / author revision`). Авторське погодження створення та публікації цього пакета не є свідченням прийняття норм будь-якою громадою. До появи її власного запису за §16.6 сайт, архів і Canon Studio повинні показувати цей статус; історія попередніх редакцій зберігається.

-----

-----

# 17. Canon as Code

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

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

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

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

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

## 17.1. Відповідність людського тексту й машинного правила {#s17-001}

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

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

## 17.2. Сталі посилання, версії та переклади {#s17-002}

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

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

## 17.3. Докази цілісності та легітимність {#s17-003}

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

-----

-----

# 18. Vilnism Canon Studio

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

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

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

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

## 18.1. Публікація без привласнення нормотворчої влади {#s18-001}

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

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

## 18.2. Доступність перевірки й заперечення {#s18-002}

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

-----

-----

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

Канон визначає права, цілі та межі повноважень. TOS або інша сумісна реалізація може допомагати виконувати прийняті правила у щоденній роботі. Встановлення програми не означає прийняття Конституції, а оновлення програми не змінює соціального договору (§§16–18).

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

## 19.1. Governance {#s19-001}

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

## 19.2. Інші модулі {#s19-002}

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

## 19.3. Resource Graph, Simulation Runtime і compute {#s19-003}

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. Межа між симуляцією та рішенням {#s19-004}

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. Архітектурні вимоги {#s19-005}

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

Незалежність мережі не означає безвідмовність окремого телефона чи сервера. Залежності конкретного розгортання — живлення, локальні дані, обладнання, ключі, команда та зовнішні послуги — повинні бути видимими. Для критичних функцій потрібні резервування й перевірений спосіб відновлення. При розриві зв'язку застосовуються локальні повноваження та правила узгодження §§31.9–31.11.

## 19.6. Граф ресурсів не створює права розпорядження {#s19-006}

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

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

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

## 19.7. Добровільне надання обчислень, зберігання та зв'язку {#s19-007}

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

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

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

## 19.8. Докази виконання та межі автоматичного приймання {#s19-008}

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

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

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

-----

-----

# 20. AI, знання та делеговане виконання

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

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

AI не повинен:

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

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

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

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

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

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

## 20.2. Обмежений мандат агента {#s20-002}

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

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

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

## 20.3. Відкликання, відключення та робота без зв'язку {#s20-003}

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

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

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

## 20.4. Незалежний контроль і людське оскарження {#s20-004}

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

Рекомендація, симуляція чи технічна більшість агентів не є голосуванням людей. Рішення, що змінює права, соціальний договір або примусовий мандат, проходить відповідну людську процедуру (§§16–18). Делегування рутинного виконання не делегує право переписувати цю процедуру.

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

## 20.5. Genesis, оновлення та самовдосконалення {#s20-005}

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

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

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

## 20.6. Межа заявлених можливостей {#s20-006}

Наведені права й обмеження є вимогами до системи. Реальна автономність, ізоляція, відкликання, переносимість контексту та відновлення підтверджуються випробуваннями конкретного профілю. Відсутній або невиконаний тест позначається прямо; назва моделі, кількість агентів чи наявність підпису не замінюють такого доказу (§49.18).

-----

-----

# 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}

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

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

### 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}

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

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

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

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

Періодичний перегляд має спрощувати непотрібні кроки, а не вимагати постійної участі всіх людей у governance (§30.11). Скорочений виклад посилається на точну чинну норму; він не додає прихованих обов’язків і не замінює гарантій. Припинення тимчасової процедури не означає автоматичного припинення базового права (§16.7).

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

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

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

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

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

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

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

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

## 29.20. Докази гарантій і чесне позначення зрілості {#s28-071}

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

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

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

## 29.21. Перевірка прав під час відмови системи {#s28-072}

До заяви про готовність конкретної реалізації відповідальний має показати сценарії, у яких перевіряються не лише працездатність коду, а й наслідки для людей. До програми §29.15 додаються: відмова засновника або головного провайдера; недоступність WebV Home чи первинного іменування; втрата ключа; розрив і відновлення зв’язку зі спірними записами; спроба повторно витратити одне обмежене право; розходження людського правила й автоматизації; вихід оператора спільного критичного ресурсу; апеляція без AI; завершення аварійного мандата при триваючій потребі в допомозі.

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

-----

-----

# 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}

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

Захист:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 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}

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

Це означає:

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

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

## 30.17. Особистий вихід, договори та поділ майна {#s29-017}

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

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

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

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

## 30.18. Процедурний захист дітей і залежних осіб {#s29-018}

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

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

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

-----

-----

# 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 воно автоматично припиняється. Для продовження потрібен новий мандат від належного незалежного джерела повноваження, а не окреме рішення про скасування. Повторні мандати обліковуються разом із сумарною тривалістю й підставами, щоб ланцюг коротких продовжень не приховував постійного надзвичайного режиму.

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

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

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

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

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

Можливі:

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

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

## 31.9. Локальна автономність під час розриву зв’язку {#s30-009}

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

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

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

## 31.10. Спільні обмежені права та ресурси при partition {#s30-010}

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

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

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

## 31.11. Відновлення зв’язку та врегулювання розбіжностей {#s30-011}

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

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

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

-----

-----

# 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, достатній для того, щоб залежні сторони створили альтернативу.

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

## 32.12. Статут спільного критичного ресурсу {#s31-012}

Сторони мережі, що покладаються на ресурс за §32.5–§32.6, повинні до виникнення критичної залежності або при її виявленні погодити окремий статут доступу. Він розрізняє титул власності, обов’язки збереження, технічне операторство та права користування; запис у TOS чи володіння ключем не замінює жодної з цих підстав.

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

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

## 32.13. Справедливий розподіл при фактичному дефіциті {#s31-013}

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

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

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

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

## 32.14. Безпечне припинення операторства {#s31-014}

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

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

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

-----

-----

# 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.

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

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

Попередньо дозволена локальна аварійна дія виконується за відповідним протоколом без очікування недосяжного глобального реєстру (§§12, 31). Журнал засвідчує події, а не створює нову надзвичайну компетенцію.

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

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

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

> **Past immutable; future forkable.**

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

Незмінність запису не означає істинності записаного твердження. Помилкові, спірні або неправомірно отримані дані повинні мати видимий статус, процедуру виправлення, обмеження доступу та оскарження. Історія рішення й запис про його виправлення зберігаються в допустимому обсязі; приватність не скасовується вимогою вічно публікувати всі персональні дані (§34.18).

## 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.

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

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

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

Особиста recovery-політика обирається людиною добровільно. Вона може залучати довірених осіб або інші перевірені засоби, але не передає їм власність на особу, її політичний голос чи всі приватні дані. Обов'язковий глобальний опікун, незамінний зовнішній signer або універсальний ключ Foundation не допускається як умова базової мережевої участі.

## 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 повинні бути відтворюваними незалежними командами.

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

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

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

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

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

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

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

Конституція не встановлює єдиного алгоритму консистентності для всіх даних. Вибір механізму має відповідати семантиці задачі, допустимій шкоді й поведінці при розриві зв'язку (§§31.9–31.11). Узгодження редагованого тексту не підміняє контроль дефіцитного ресурсу; захист від застарілого виконавця не створює миттєвого глобального знання.

## 34.15. Різні ідентичності та право на контекст {#s33-015}

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

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

## 34.16. Ротація, компрометація та відновлення {#s33-016}

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

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

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

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

## 34.17. Цілісність, походження, повноваження, правильність і доступність {#s33-017}

Ці властивості перевіряються окремо:

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

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

## 34.18. Приватність копій, зберігання та виправлення {#s33-018}

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

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

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

## 34.19. Відновлюваність довіри без світового адміністратора {#s33-019}

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

Після втрати зв'язку чи частини історії система показує, що саме їй відомо, за який період і з яких джерел. Відновлення за старою копією не означає, що вона є найновішою у світі. Нові повноваження не виводяться з самого факту виживання вузла; застосовуються §§31, 49 та заздалегідь погоджені процедури.

-----

-----

# 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 або інший один метод. Для кожного заявленого класу забруднення потрібен валідований бар'єр і тестовий критерій.

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

## 35.30. Паспорт місцевої спроможності {#s34-049}

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

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

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

## 35.31. Навчання без примусової універсальної спеціалізації {#s34-050}

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

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

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

-----

-----

# 36. Vilnism Civilization OS: інфраструктура, а не власна імперія (новий розділ, додано у v0.8)

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

WebV (§49) задає окрему пропозицію відкритого мережевого протоколу. TOS може реалізовувати операційне середовище поверх цього протоколу або працювати локально без нього. Соціальна модель Вільнізму, технічна сумісність WebV та вибір програми є різними рішеннями учасника.

## 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, пошук і виконання в межах відкличного мандату (§20).
10. **WebV interoperability layer** — незалежні ідентичності, виявлення учасників, контент і транспорт між автономними доменами; він не створює влади над ними.

## 36.2. Federation first {#s35-002}

Будь-який критичний сервіс має проєктуватися так, щоб громада могла self-host, export, mirror або замінити implementation. Протокол важливіший за конкретний сервер. Відкриті API, open formats і portable identity мають підкріплюватися перевіркою реальної заміни постачальника та відновлення даних: сам напис «відкритий» не усуває залежність.

Громада може входити в кілька функціональних мереж і зберігати локальні повноваження при втраті міжмережевого зв'язку (§31). Один агрегований граф не стає світовою базою істини або єдиним розпорядником ресурсів.

## 36.3. Стандарт сильніший за монополію {#s35-003}

Мета — не юридично закріпити монополію Vilnism, а створити стандарт, який добровільно використовується через корисність, сумісність і network effects. Конкурент завжди має право створити кращу реалізацію або fork протоколу.

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

## 36.4. Розподіл повноважень між шарами {#s35-004}

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

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

## 36.5. Принцип, пропозиція і перевірена можливість {#s35-005}

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

Для переходу від початкової інфраструктури до незалежної мережі потрібні відтворювані докази за §§49.16–49.18. Довгострокова мета Civilization OS не є заявою, що така цивілізаційна система вже побудована або що її соціальна ефективність доведена.

-----

-----

# 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. Від стрічки до накопичуваного знання {#s37-001}

Соціальна мережа Civilization OS не повинна винагороджувати нескінченний scroll, outrage або саму популярність. Її базові об’єкти — Problem, Question, Proposal, Evidence, Prototype, Experiment, Replication, Failure, Standard, Project і Request.

## 38.2. Social Knowledge Compiler {#s37-002}

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

- знаходити дублікати і попередні спроби;
- будувати argument maps;
- відділяти факт, припущення, норму й метафору;
- формувати RFC і test plan;
- пов’язувати дискусію з hardware/software repositories;
- відстежувати незалежні replication attempts;
- створювати living summaries замість втрати знання у хронологічній стрічці.

## 38.3. Challenge System {#s37-003}

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

## 38.4. Open engineering package {#s37-004}

Для фізичного рішення стандартний пакет за можливості включає: 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 {#s37-005}

Форум є не лише місцем дискусії. Для 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 {#s37-006}

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 має перевагу над тотальним профілюванням.

## 39.5. Межі використання репутаційного запису {#s38-005}

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

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

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

-----

-----

# 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. Технологічна сумісність не дорівнює монетарному суверенітету платформи.

## 40.7. Переносимість прав без обіцянки миттєвої ліквідації {#s39-007}

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

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

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

## 40.8. Мінімальні умови міжоператорної угоди {#s39-008}

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

Облік розділяє пропозицію, резервування, підтверджений обов’язок, фактичне виконання та завершений розрахунок. Повторне повідомлення не повинно створювати повторної вимоги за одну операцію; поведінка при розриві зв’язку й суперечливих підтвердженнях визначається за §§31.9–31.11. Наявність криптографічного запису не доводить якості фізичної поставки або правомірності рахунка.

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

-----

-----

# 41. Settlement Network, Civilization Graph і довгострокова безперервність (новий розділ, додано у v0.8)

## 41.1. Глобальна мережа поселень {#s40-001}

Vilnism має спочатку підключати реальні існуючі communities, а не вимагати, щоб вони стали “містами Vilnism”. Verified community profile може містити governance, land model, population, infrastructure, projects, needs, failures, technologies, research і канали співпраці, які сама community погодилася публікувати.

## 41.2. Партнерська позиція {#s40-002}

Перший контакт із практиками має виходити з асиметрії досвіду: у них є реальні роки експлуатації, у Vilnism — інструмент систематизації. Платформа просить critical review і operational evidence, а натомість повертає structured knowledge, comparisons, open tools і доступ до ширшої мережі. Союз означає інфраструктурну кооперацію, а не підпорядкування Canon.

## 41.3. Civilization Graph {#s40-003}

Граф пов’язує:

- 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 {#s40-004}

Замість одного числа використовується 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 {#s40-005}

Довгострокова мета — не просто архів текстів, а dependency-complete карта від базових ресурсів і простих інструментів до складної промислової цивілізації, з можливістю offline reproduction. VSS/VCRP є нижніми щаблями цієї системи.

## 41.6. Civilization memory {#s40-006}

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

## 41.7. Кінцева мета {#s40-007}

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

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

-----

## 41.8. Executable Civilization Graph {#s40-008}

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: цифровий двійник реальної спроможності {#s40-009}

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

Тоді tech tree підсвічує не абстрактно «винайдені» технології, а:

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

## 41.10. Reality ↔ Simulation Loop {#s40-010}

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 як видимий стан цивілізації {#s40-011}

Якщо система знає, що технологія існує, але не має перевіреного dependency-complete шляху її відтворення, це не маскується під «knowledge available». Створюється `KnowledgeGap` з рівнем критичності, причиною, потрібними експериментами, зовнішніми джерелами та статусом незалежної реплікації.

Глобальним квестом Civilization OS стає поступове скорочення таких gaps: **описати цивілізацію настільки добре, щоб її критичні функції можна було відновити з відомих нижчих рівнів або чесно знати, де це поки неможливо**.


## 41.12. Technology Node lifecycle {#s40-012}

Кожний вузол 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 {#s40-013}

Civilization Simulation Game використовує перевірену частину графа як reality anchor, а frontier layers — як простір сценаріїв. Людські партії можуть, за явної згоди й із захистом приватності, зберігатися як simulation traces.

AI може знаходити незвичайні стратегії, які стабільно переживають stress scenarios, і створювати з них `ResearchCandidate`. Такий candidate повертається на Forum/Labs і не переходить у реальний стандарт, доки не пройде окрему перевірку.

## 41.14. Distributed Simulation Compute {#s40-014}

Великі 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. Єдиний цикл розвитку {#s40-015}

Довгостроковий цикл 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.

## 45.14. Межі заяви про готовність {#s44-014}

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

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

Після втрати критичного персоналу, обладнання, запасу чи зовнішнього партнера оператор переглядає профіль до наступної планової перевірки. Закінчення строку оцінки саме собою не вимикає життєзабезпечення: відповідальний позначає невизначеність, перевіряє ризик, залучає резерв і звужує непідтверджені обіцянки. Фізична допомога й повноваження на її організацію зберігають власні підстави та межі за §§12 і 32.

-----

-----

# 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}

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

-----

# 49. Web V — шлях до свободи

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

Цей розділ установлює конституційні вимоги до такого протоколу та його застосування. Архітектурні документи мають статус пропозицій; ця редакція не проголошує завершеного міжнародного стандарту, готового WebV runtime або доведеної глобальної стійкості. Реалізація, випробування та прийняття людьми є окремими процесами (§§16–18, 49.18).

TOS є однією з reference implementations і лабораторією реалізації. Civilization OS — довгострокове добровільне застосування координаційних механізмів до громад та цивілізаційних ресурсів. Користування WebV не зобов'язує приймати Вільнізм, використовувати TOS або підпорядковуватися Foundation.

## 49.1. Чотири створює систему, п'ять дає їй сенс: пояснювальна символіка {#s48-001}

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

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

> **Машина може оптимізувати шлях. Напрямок визначає людина.**

## 49.2. Від Web 4.0 до Web V {#s48-002}

У необов'язковій внутрішній моделі пояснення:

- **Web 1.0 — Information:** доступ до інформації;
- **Web 2.0 — Participation:** участь, публікація та соціальні платформи;
- **Web 3.0 — Ownership:** криптографічна власність, portable identity та децентралізовані активи;
- **Web 4.0 — Agency:** персональні AI-агенти, ноди, автономні сервіси, суверенні дані та машинна дія від імені людини в межах її правил;
- **Web V / Web 5.0 — Civilization:** добровільна координація суверенних людей і систем на рівні спільнот, організацій, економік і цивілізаційної інфраструктури.

Назви цих етапів є внутрішньою концептуальною моделлю Foundation. Це не загальноприйнята історична періодизація, доказ технічного прогресу або обов'язкова послідовність для реалізатора. Властивості WebV визначаються відкритою специфікацією й перевірками, а не номером покоління Інтернету.

## 49.3. V = Five = Vilni {#s48-003}

V читається одночасно як римська п'ятірка і як перша літера **Vilni — Вільні**.

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

Робоча термінологія:

- **Vilni** — суверенний людський учасник;
- **Node** — пристрій або програмний вузол із визначеним оператором, можливостями та межами доступу;
- **Agent** — автономний цифровий виконавець із делегованими повноваженнями;
- **TOS** — одна з практичних reference implementations персонального та організаційного середовища;
- **Civilization OS** — набір відкритих координаційних механізмів;
- **WebV** — пропонований відкритий протокол взаємодії незалежних учасників; його цивілізаційне застосування ширше за будь-який окремий продукт.

## 49.4. Шлях до свободи {#s48-004}

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

Технологія має збільшувати choice space людини, а не приховано звужувати його. Звідси випливають базові вимоги:

- контроль над власними даними та можливість експорту;
- право змінити AI-провайдера або працювати локально;
- можливість self-hosted і federated режимів;
- відсутність прихованого рекламного керування поведінкою як системної мети;
- portable identity та portable social graph там, де це безпечно;
- явні межі повноважень агентів;
- право на відключення автоматизації;
- право вийти зі спільноти або системи без штучного цифрового ув'язнення;
- мінімізація single points of control.

Людина має право на зрозуміле пояснення умов, доступний спосіб оскарження та участь без обов'язкової технічної експертності. Ці права не зникають через втрату ключа, пристрою, зв'язку або відмову від AI (§§20, 34).

## 49.5. Civilization OS як міст {#s48-005}

Civilization OS не повинна бути централізованою «операційною системою суспільства». Її роль — зменшувати координаційну складність між людським рішенням і його виконанням.

Люди визначають цілі та правила. Система може допомагати з моделями, бюджетами, сценаріями, перевірками, виконанням, аудитом і збереженням історії. Рутинне виконання може бути заздалегідь делеговане в обмежених межах (§20); зміна прав або мандатів потребує відповідної процедури. Чим вищий ризик рішення, тим сильнішими мають бути вимоги до людського контролю, прозорості та виправлення наслідків. Незворотний фізичний наслідок не зникає від програмного rollback.

## 49.6. TOS і Foundation {#s48-006}

TOS не тотожний Web V. TOS може бути першою або однією з reference implementations і лабораторією практичної перевірки принципів.

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

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

## 49.7. Споріднені цивілізаційні проєкти {#s48-007}

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

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

## 49.8. П'ять сил Web V {#s48-008}

Для необов'язкового пояснення архітектури використовується модель п'яти сил:

1. **Knowledge** — інформація, пам'ять, знання і provenance;
2. **Compute** — пристрої, ноди, мережі, енергія та фізичні ресурси;
3. **Economy** — власність, платежі, обмін і розподіл ресурсів;
4. **Intelligence** — AI, агенти, автоматизація і моделювання;
5. **Will** — людська воля, цілі, цінності, згода та відповідальність.

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

## 49.9. Місія {#s48-009}

Місія поєднує практичне створення відкритого протоколу й довгострокове розширення добровільної співпраці:

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

Коротка формула:

> **V is Five. V is Vilni. V is the path to freedom.**

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

## 49.10. Незалежна адресація та необов'язковий Home {#s48-010}

У native-профілі WebV існування й відкриття незалежного сайту чи сервісу за відомою перевірюваною ідентичністю не повинно вимагати дозволу одного DNS-оператора, каталогу, TOS-акаунта або Foundation. Звичайний вебшлюз може використовувати DNS та HTTPS; його залежності позначаються окремо і не видаються за доказ незалежності всього протоколу.

Home, умовний ID 0 і home.html можуть бути зручним початковим каталогом або точкою входу певної спільноти. ID 0 має значення в названому просторі імен, а не є єдиним світовим ключем адресації. Недоступність Home, відмова в розміщенні або спір його операторів не повинні блокувати відомий незалежний SiteID, інший каталог або власний простір імен.

## 49.11. Походження, оновлення та переносимість {#s48-011}

Ідентичність учасника, ноди, сайту та незмінної версії контенту розділяються (§34.15). Оновлення контенту не повинно без необхідності змінювати стабільну ідентичність сервісу; зміна ключа проходить окрему перевірювану процедуру (§34.16).

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

## 49.12. Виявлення учасників без прихованого центру довіри {#s48-012}

Каталоги, локальне виявлення, запрошення, збережені контакти, DHT та початкові bootstrap-вузли є способами знайти можливий маршрут. Перший знайдений вузол не отримує права визначати особу, її політику або всі подальші дозволи.

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

## 49.13. Канали зв'язку та фізичні межі {#s48-013}

WebV має підтримувати замінні транспортні профілі: наявний Internet, Ethernet та локальні мережі, Wi-Fi, доступні mesh-маршрути, добровільні ретранслятори й відкладене перенесення повідомлень. Додаткові радіоканали можуть застосовуватися за наявності обладнання, сумісності й належних умов використання; жоден конкретний радіоканал не є обов'язковою властивістю всіх пристроїв.

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

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

## 49.14. Локальні острови й повторне з'єднання {#s48-014}

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

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

## 49.15. Добровільна участь, захист від зловживань і межі каталогу {#s48-015}

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

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

Технічна сумісність, право виконати конкретну операцію та соціальне членство перевіряються окремо. Базовий протокол не вимагає обов'язкового токена, купівлі місця в каталозі або передачі ключів за дешевше обчислення. Окремі погоджені послуги можуть мати прозору ціну (§§19, 32, 40).

## 49.16. Від початкової інфраструктури до самостійної мережі {#s48-016}

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

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

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

## 49.17. Умови відмови від обов'язкового центрального сервера {#s48-017}

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

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

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

## 49.18. Паспорт гарантій і перевірені докази {#s48-018}

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

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

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

## 49.19. Безперервність людських прав при технологічному відновленні {#s48-019}

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

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