# Vilnism Civilization OS — Architecture Specification **Версія:** 0.7 **Дата:** 2026-10-30 **Статус:** review / companion / proposed architecture **Узгодження:** Canon corpus v0.17.0; Foundation v0.15.0; Canon Studio v0.5.0 **Runtime-докази цього документа:** NOT_RUN **Мова:** українська Це супровідна архітектурна пропозиція. Вона пояснює можливі механізми реалізації норм, але не приймає конституцію за громаду, не є специфікацією завершеного мережевого стандарту й не засвідчує готовність перелічених компонентів. Слова «система», «runtime», «solver» і назви шарів нижче описують цільову архітектуру, якщо конкретний версійований звіт окремо не доводить реалізацію та перевірку. Збірка документа або сайту не є випробуванням WebV, TOS чи Civilization OS. Нормативні межі визначає прийнята у відповідному домені редакція Конституції. Для релізу v0.17.0 це, зокрема, §§16–20, 31–34, 36 та 49. Пропозиція механізму не може непомітно змінити норму, обсяг згоди або права людей. ## 1. Призначення Vilnism Civilization OS — добровільна федеративна архітектура прикладних інструментів, даних і договорів. Її мета — допомагати людям та громадам створювати, тестувати, порівнювати й успадковувати суспільні та технологічні рішення. Вона не набуває власності на поселення, політичної юрисдикції або влади над учасниками через сам факт використання програмного забезпечення. WebV пропонується як незалежно реалізовний відкритий протокол сумісності. TOS є однією референсною реалізацією операційного середовища та його профілів. Civilization OS може добровільно використовувати ці можливості або іншу сумісну реалізацію. Доступ до WebV не вимагає прийняття Вільнізму; прийняття Вільнізму не вимагає одного постачальника runtime. Довгострокова суспільна місія не створює глобального адміністратора мережі. Ключова формула: > **Не побудувати правильний світ. Побудувати систему, в якій людство може безперервно створювати кращі світи.** ## 2. Civilization Evolution Loop Базовий workflow: **Problem → Proposal → Prototype → Test → Independent Replication → Adoption → Standard → New Criticism.** Кожний стан повинен мати provenance, version history, evidence links, known failures та можливість fork. Наукова реплікація, технічна відповідність, публікація релізу, локальне прийняття норми та набуття нею чинності — окремі події. Успішний тест не приймає суспільне правило автоматично; merge у Canon Studio не є голосуванням громади. Передбачаються дата чинності, перехідні умови й оскарження відповідно до §§16–18 Конституції. ## 3. Основні об'єкти даних - Person; - Community; - Organization; - Competency; - Problem; - Challenge; - Proposal; - Evidence; - Prototype; - Experiment; - Replication; - Failure Report; - Standard; - Technology; - Dependency; - Project; - Resource; - Need; - Agreement; - Asset; - Contribution; - Fork; - AuthorityDomain; - Identity / KeyEpoch; - DelegatedMandate; - ResourceOffer / Reservation; - OperationReceipt / VerificationRecord; - AdoptionRecord; - DependencyProfile / RecoveryProfile. Це семантичні сутності проєкту, а не затверджений wire-format. Запис про людину, ключ, вузол чи ресурс не доводить їхню тотожність і не надає прав керування. ## 4. Шари системи ### 4.1. Canon / Foundation Цінності, права та порядок прийняття норм. Гіпотези, патерни, технічні профілі й допоміжні стандарти мають явний статус і не отримують конституційної сили лише через розміщення поруч із Canon. ### 4.2. Canon Studio Version control, proposals, forks, diffs, evidence, contradiction analysis, provenance та reproducible releases. Мейнтейнер публікує артефакт у межах свого мандата; громада окремо приймає норму. Підпис релізу підтверджує походження байтів за ключем, а не законність ухвалення. ### 4.3. Civilization Wiki Практичні knowledge packages. Для фізичних технологій: BOM, CAD, code/firmware, materials, tools, assembly, repair, safety, substitutions, cost, test data, installations і failures. ### 4.4. Science Commons Challenges, hypotheses, research teams, open notebooks, peer review, replication, negative results і standards. ### 4.5. Settlement Network Профілі громад: governance, infrastructure, economy, open projects, needs, competencies та published lessons. Позначка verified має посилатися на конкретне твердження, метод, версію, перевіряльника, дату та межі перевірки; вона не є універсальним знаком доброчесності громади. ### 4.6. Civilization Graph Граф зв'язків між людьми, skills, communities, resources, projects, technologies, dependencies, evidence і outcomes. Видимість або індексація ресурсу не означає право ним розпоряджатися. Приватні зв'язки, адреси й ключі не стають публічними через включення до графа. ### 4.7. Project / Talent / Capital Marketplace Matching проблем і ресурсів без переходу платформи у власність над людьми або communities. ### 4.8. Intercommunity Protocol Open contracts, mobility, residency, joint ventures, asset portability, mutual aid і dispute resolution. ### 4.9. AI Orchestration Layer Пошук, переклад, synthesis, deduplication, routing, argument maps, RFC drafting, matching та делеговане виконання. Для дій потрібен чинний обмежений мандат: суб'єкт, мета, ресурс, строк, бюджет, допустимі наслідки й спосіб відкликання. Дочірній агент не отримує більше прав, ніж батьківський; сукупне делегування не множить ліміти. Рутинні дії в уже схваленому мандаті не вимагають нового підтвердження кожного кроку. AI не має суверенного права ухвалювати рішення за людей, змінювати власні повноваження або конституцію. Контроль над даними, доступами й виходом важливіший за походження моделі: власне локальне навчання не обов'язкове. Genesis означає лише дозволене розгортання у визначених ресурсах, а не самовільне розширення мережі. Вимоги — §20 Конституції. ### 4.10. Forum / Human R&D Layer Кожний `KnowledgeGap`, Technology Node, Standard або failure pattern може мати прив'язаний discussion/RFC/test space. Форум компілює дискусію в структуровані research artifacts, а не зберігає лише chronology. ### 4.11. Civilization Simulation Runtime Пропонується сумісна модель даних для interactive game, headless research, governance sandbox і real-settlement digital twin; незалежні engines можуть реалізовувати її профілі. Runtime має читати versioned snapshots і не змінювати реальний Resource Graph без окремого authorization path. Детерміноване відтворення симуляції не доводить точність моделі фізичного світу. ### 4.12. TOS Operational Runtime TOS пропонує нейтральний operational substrate: Resource Graph, tasks/jobs, Scenario/Simulation execution, audit, local/cluster compute, adapters to physical/digital infrastructure та future Compute Exchange. Він є однією реалізацією, а не власником WebV. Vilnism є однією reference civilization model, а не обов'язковою ідеологією TOS. Наявність кожної можливості, її профіль безпеки та interoperability перевіряються окремо; цей companion не оголошує їх реалізованими. ### 4.13. Distributed Compute Fabric Цільова схема допускає виконання simulation jobs на local node, Private Grid, settlement cluster або добровільно обраному зовнішньому постачальнику. Job/shard identity, версія моделі, receipts і provider policy допомагають зв'язати результати з операцією. Вони не доводять правильність результату без відповідного verifier, не гарантують доступність і не створюють право на оплату без умов договору. Окремо обліковуються допуск, резервування, виконання, отримання результату, перевірка, прийняття й розрахунок. Невідомий результат не позначається успішним, а втрата відповіді не означає відсутності фізичного або фінансового ефекту. Застосовуються §§19.6–19.8, 32.14 та 40.8 Конституції. ### 4.14. WebV Protocol Layer Незалежно реалізовні профілі ідентичності, публікації, discovery, transport, локальних сервісів і ресурсних договорів. Пошук та Home є замінними сервісами. Жодний вузол, каталог, DNS-домен, bootstrap-сервер або Foundation не становить обов'язкового глобального кореня. Вимоги та відкриті рішення описані у research/web_v v0.2; wire-standard і готова мережа цим текстом не оголошуються. ## 5. Social Knowledge Compiler Платформа повинна перетворювати інформаційний шум на накопичуване знання. Хронологічний feed не є головною одиницею системи. Рекомендовані переходи: - comment → claim; - claim → evidence request; - recurring discussion → structured question; - question → proposal; - proposal → RFC/test plan; - prototype → test record; - tests → replication status; - repeated success → candidate standard; - failure → failure pattern. ## 6. Репутація Заборонений один загальний social score людини. Допустимі domain-specific records: - verified competency; - contracts delivered; - safety record; - replicated contributions; - peer-review quality; - project delivery; - dispute outcomes with appeals. Наукові та канонічні пропозиції за можливості проходять blind review. Репутація автора не є аргументом істинності. ## 7. Feed design Default feed повинен віддавати пріоритет: - Problems; - Projects; - Experiments; - Results; - Replication Needed; - Requests; - Failure Reports; - New Standards; - Community Needs. Outrage, політична популярність та follower count не є основними ranking signals. ## 8. Federation and anti-capture Критичні вимоги: - self-hosting; - open protocols; - open source reference implementation; - export all user/community-owned data; - portable identity/credentials; - mirrored public knowledge; - multiple independent clients; - no exclusive global write authority; локальні записи залишаються під чинними правами відповідного домену; - forkability; - cryptographic provenance; - no single mandatory AI provider; - явний життєвий цикл ключів: rotation, revocation, recovery, conflict handling; - перевірений вихід із залежності від центрального оператора; - профілі доступності та локального відновлення з виміряними межами. Набір peer IDs або копій одного сервісу не доводить незалежності. Профіль має враховувати операторів, адміністративні ключі, майданчики, живлення, маршрути, запаси, фінансування й навички. Політичний голос не купується потужністю, stake, кількістю вузлів або ресурсним внеском. Особиста ідентичність не передається громадському threshold-ключу; інституційні критичні ключі мають окремі колективні правила відповідно до §34.8. ## 9. Civilization Reproducibility Profile Не один score, а capability tree: water, shelter, sanitation, food, energy, medicine, communications, logistics, fabrication, machine tools, chemistry, materials, electronics, computing, software, agriculture, construction, education, governance, emergency recovery. Для кожного layer: - local capability; - external dependencies; - critical knowledge availability; - tools/equipment; - repairability; - replacement lead time; - offline documentation; - trained people; - replication evidence. ## 10. Civilization Backup Мета — dependency-complete archive, що пояснює не лише як користуватися технологією, а як відтворити її toolchain від нижчих рівнів. VSS/VCRP покриває нижній recovery layer. Civilization Backup розширює його до промислової та наукової цивілізації. ## 11. Головна метрика платформи Не users, DAU чи valuation як самоціль. Ключові системні метрики: - час problem → replicated solution; - кількість незалежних реплікацій; - частка knowledge packages з повним provenance; - кількість communities, що реально повторили рішення; - зменшення критичних dependency gaps; - здатність нового поселення стартувати з готових відкритих модулів; - portability між implementations; - замінність критичних центрів контролю, підтверджена для конкретного профілю відмов. Ці метрики характеризують систему та якість процесу; вони не агрегуються в бал цінності людини й не замінюють права. Для показника зазначаються джерело, покриття, невизначеність, ризик маніпуляції та спосіб незалежної перевірки. ## 12. Forum-to-Graph Research Compiler Technology Graph не вважається відомим наперед. Його оптимальні ланцюги, реальні costs, tool dependencies, failure modes і test procedures поступово встановлюються спільнотою. Мінімальний lifecycle: ```text KnowledgeGap ↓ Forum Topic / Challenge ↓ Proposal / RFC ↓ Prototype ↓ Lab Test ↓ Field Test ↓ Independent Replication ↓ Verified Technology Node ↓ Simulation/Game Release ``` Кожний перехід має evidence, actor/source attribution, timestamps і можливість reopen після failure report. ## 13. Game Bootstrap Strategy Civilization Simulation Game може бути першою великою public-facing метою платформи. Маркетингова теза проста: **створити гру, де tech tree не вигаданий дизайнером, а максимально спирається на реальну відтворювану цивілізацію.** Не потрібно чекати 100% completeness. Release gate задається coverage profile: достатня кількість verified chains для gameplay core, а невідоме явно маркується й може ставати research quest. Як гіпотеза продуктового розвитку, гра може: - фінансувати/популяризувати наповнення graph; - навчати причинно-наслідковим залежностям; - генерувати simulation traces; - знаходити незвичайні human strategies; - надавати зрозумілий інтерфейс до сумісної simulation model, яку TOS або інша реалізація зможе запускати headless. Фінансування, попит, педагогічний ефект і сумісність тут є перевірюваними гіпотезами, а не обіцяними результатами. Гра не є обов'язковим способом входу до WebV чи прийняття Canon. ## 14. Reality + Frontier Model Simulation не обмежується сьогоднішніми технологіями. Кожний technology node має epistemic layer: verified real, engineering known, research, theoretical, speculative або fictional. Reality mode використовує лише допустимі рівні evidence. Future/scenario modes можуть вмикати frontier nodes із широкими uncertainty distributions. Художня кінематографічність гри зберігається, але не підміняє verified reality. ## 15. Compute as a Resource Domain Compute є таким самим ресурсом Civilization OS, як енергія чи виробниче обладнання, але з особливими security constraints. TOS Resource Graph може описувати CPU, GPU, RAM, storage, network, availability, energy/thermal budgets і provider policy. У запропонованому workflow Simulation Planner розкладає batch на shards, Scheduler обирає лише дозволені ресурси, Verification застосовує придатний до задачі метод, а settlement/economy layer обліковує виконані договірні умови. Придатність verifier, ізоляція workload, енерговитрати, приватність і ціна перевірки мають бути вказані до прийняття job. Власник ресурсу добровільно задає доступний обсяг, часові вікна, ліміти потужності, бюджет, правила даних і виходу. Ресурсна пропозиція не дає іншим сторонам права використовувати весь пристрій. Відкликання не стирає вже взятих зобов'язань і не створює небезпечного миттєвого вимкнення критичної фізичної послуги. Малі вузли, низька пропускна здатність або відсутність енергії обмежують реальні функції: мережа не обіцяє GPU-обчислення чи відео там, де потрібні ресурси недоступні. ## 16. Довгострокова теза Vilnism має стати не власником цивілізації, а її відкритою пам'яттю, конструктором і протоколом сумісності. ## 17. Cognitive & Systemic Sovereignty Layer ### 17.1. Призначення Civilization OS захищає не лише формальне право людини голосувати, володіти майном або залишати громаду, а й **здатність самостійно формувати рішення**. Когнітивний суверенітет означає, що людина повинна мати реальну можливість: - відрізняти факт, інтерпретацію, гіпотезу, сценарій і метафізичну модель; - бачити більше ніж одну рамку проблеми; - не приймати незворотне рішення лише через штучно створену терміновість, страх, сором, гнів або ейфорію; - вимагати provenance і первинні дані; - змінювати власну позицію без автоматичної втрати соціального статусу; - відмовлятися від масового ритуалу лояльності; - користуватися альтернативними інформаційними, технологічними та економічними каналами; - сказати «ні», запропонувати третій варіант, зробити fork або вийти. Цей layer не припускає існування єдиного прихованого центру контролю. Джерелом когнітивного захоплення може бути держава, корпорація, медіа, релігійна чи політична структура, харизматичний лідер, більшість самої громади, AI-система, помилкова метрика або модель, яку ніхто більше не перевіряє. Ключова формула: > **Захищати не «правильну думку», а здатність людини думати, перевіряти, сумніватися і змінювати висновок.** ### 17.2. Межа протоколу: anti-manipulation не є міністерством істини Civilization OS не отримує повноваження визначати обов'язкову картину світу. Система може: - показувати джерела і provenance; - відділяти дані від інтерпретацій; - показувати невизначеність; - виявляти конфлікти інтересів; - представляти сильні альтернативні моделі; - попереджати про відомі маніпулятивні патерни; - зберігати dissent і minority reports. Система не може лише на підставі «захисту від дезінформації»: - заборонити мирну незгоду; - створити рейтинг ідеологічної лояльності; - вимагати публічних ритуалів підтримки; - трактувати відсутність підтримки як доказ ворожості; - давати одній установі монополію на визначення істини. Анти-маніпуляційний механізм, який сам отримує монополію на інформацію, вважається **capture risk**. ### 17.3. Epistemic State Model Для high-impact claims використовується явний epistemic status: ```text FACT STRONG_EVIDENCE PLAUSIBLE HYPOTHESIS SPECULATION METAPHYSICAL SCENARIO UNKNOWN ``` Статус є оцінкою **конкретного твердження** за визначеними критеріями й джерелами, а не властивістю особи автора чи гарантією документа. Навіть позначка FACT потребує provenance, меж перевірки та процедури виправлення. Програмне присвоєння статусу не робить його політично обов'язковою істиною. Мінімальний claim record: ```yaml claim: id: "" statement: "" epistemic_status: "" primary_sources: [] independent_sources: [] alternative_models: [] counterevidence: [] conflicts_of_interest: [] uncertainty: "" falsification_or_revision_conditions: "" last_reviewed: "" ``` Для high-impact або незворотних суспільних рішень одне неперевірюване джерело не вважається достатньою підставою для остаточного висновку, якщо існує реальна можливість незалежної перевірки. Водночас принцип не перетворюється на догму `One Source = False`: іноді первинне джерело справді може бути єдиним доступним свідченням, тому статус такого claim залишається **provisional / uncertainty explicit**. Обов'язково розділяються: **Data → Observation → Interpretation → Conclusion → Normative/Policy Recommendation.** Перехід між цими рівнями не може бути прихованим. ### 17.4. Cognitive Cooling & Reversibility Чим сильніша емоційна активація і чим менш оборотне рішення, тим сильніший повинен бути time barrier. Базова матриця: ```text low impact + reversible → immediate allowed medium impact → pause encouraged high impact + reversible → independent review high impact + irreversible → cooling period + alternative analysis + objection window immediate physical danger → emergency action allowed + mandatory after-action review ``` Фіксовані години не є універсальним канонічним законом: тривалість залежить від шкоди затримки, оборотності та ризику рішення. Перед великою незворотною дією система повинна допомогти людині або групі відповісти: 1. Що саме ми зараз відчуваємо? 2. Який incentive має сторона, що вимагає негайної дії? 3. Що станеться, якщо рішення буде відкладено? 4. Які варіанти не потрапили у поточну рамку? 5. Які дані могли б змінити нашу позицію? Якщо відповідь на п'яте питання фактично «жодні», твердження може потребувати підвищеного review як неперевірюване в поточній постановці. Це не психологічний діагноз людини, не показник її лояльності й не підстава обмежити права; оцінка та її підстави доступні для оскарження. ### 17.5. Choice-Space Integrity Захоплення порядку денного може відбутися до голосування — через визначення набору допустимих варіантів. Для значних рішень Civilization OS зберігає: - `status_quo`; - запропоновані альтернативи; - `no-action option`; - локальні/часткові рішення; - minority proposal; - можливість розбити проблему на незалежні підрішення; - пояснення того, хто сформував choice set. Застосовується **Third-Space Check**: > **Чому простір рішення складається саме з цих варіантів?** Бінарна постановка `A або B` не приймається як природна лише тому, що вона популярна. ### 17.6. Steelman & Minority Channel Для high-impact dispute застосовується `Steelman Protocol`. Перед спростуванням позиції сторона повинна сформулювати її настільки точно, щоб її реальний прихильник міг підтвердити коректність викладу або запропонувати виправлення. Кожне велике governance decision може зберігати: - majority rationale; - minority report; - unresolved evidence; - rejected alternatives; - conditions for reopening the question. Consensus не стирає dissent. Меншість не отримує автоматичного veto, але її найсильніша аргументація та evidence залишаються частиною історії рішення. ### 17.7. Dual Red-Team Protocol Для рішень із високою ціною помилки використовуються дві незалежні критичні ролі. **Adversarial Red Team** Припускає, що домінуюча модель неправильна, і шукає: - hidden assumptions; - framing errors; - groupthink; - conflict of interest; - missing alternatives; - manipulation vectors; - failure modes. **Benign-Explanation Team / Advocate of the System** Коли громада переконана у зловмисності зовнішньої системи, ця команда будує найсильніше незловмисне пояснення тих самих фактів: - incompetence; - bureaucratic inertia; - emergent behavior; - coordination failure; - economic incentives; - unintended consequences. Мета dual red-team — не «захистити систему» чи «довести змову», а зменшити помилки attribution. Red Team є тимчасовою функцією, а не постійною політичною кастою. Де це практично можливо, склад критичних review-команд визначається ротацією або жеребом із відсівом явних конфліктів інтересів, щоб роль «професійного опонента» не перетворилась на новий центр влади. ### 17.8. Sovereignty of Attention Увага розглядається як обмежений людський ресурс. Базові суспільні інтерфейси Civilization OS не повинні оптимізуватися під maximal screen time, compulsive checking або outrage. Minimum interface rights: - notifications off/minimal by default для некритичних подій; - chronological mode; - explainable recommendation mode; - повне вимкнення personalization; - відсутність infinite-scroll як необхідного способу отримати governance information; - відсутність dark patterns; - export subscriptions/filters; - можливість отримати стислий scheduled briefing замість постійного feed; - offline та low-stimulation modes. Для особистої інформаційної дієти рекомендується розрізняти три шари: - **Operational** — інформація, яка реально потрібна для рішень сьогодні; - **Strategic** — повільний аналіз довших тенденцій; - **Noise/Stimulation** — контент, який систематично змінює емоційний стан, але не змінює жодної реальної дії. Практичний тест: > **Якщо інформація не змінює твоїх дій, але постійно змінює твій емоційний стан, можливо, ти споживаєш не інформацію, а стимуляцію.** Цей принцип доповнює §7 `Feed design` і anti-capture заборону купівлі людської уваги, але не забороняє добровільні розважальні продукти. ### 17.9. Cognitive Safe Mode Людина має право тимчасово зменшити інформаційне навантаження без втрати базових прав або статусу. `CognitiveSafeMode` може означати: - pause social feeds; - один стислий operational briefing; - тимчасову відмову від політичних дискусій; - мінімум некритичних notifications; - відновлення сну та звичайної фізичної рутини; - повторну оцінку high-impact information після стабілізації. Safe Mode не блокує emergency alert, який реально необхідний для фізичної безпеки. ### 17.10. Crisis Epistemic Mode Під час війни, катастрофи, епідемії, фінансової паніки або іншої системної кризи активується окремий режим, сумісний із Emergency Governance. У ньому: - emergency claim зберігає джерело, timestamp і confidence; - факт і policy interpretation зберігаються окремо; - незворотні non-emergency зміни сповільнюються; - minority report не відключається; - emergency restrictions мають scope і sunset; - після кризи проводиться evidence + rights after-action review; - страх або популярність позиції самі по собі не створюють достатньої доказової підстави. Crisis Epistemic Mode не має права автоматично активувати censorship, generalized surveillance або loyalty scoring. ### 17.11. Language & Frame Integrity Мова є інструментом опису, але ярлик не є доказом. Для ключових governance terms зберігаються: - canonical definition; - history of revisions; - aliases; - contested meanings; - translation variants; - references to source texts. Слова на кшталт «зрадник», «ворог», «єретик», «антинауковий», «фашист», «екстреміст», «конспіролог», «небезпечний» або «непатріотичний» можуть описувати реальні категорії в конкретному правовому чи аналітичному контексті, але **не закривають доказову процедуру самою своєю появою**. `Label != Evidence`. Neo-Logos і canonical glossary повинні збільшувати точність смислу, а не створювати монополію однієї установи на допустимі поняття. ### 17.12. Separation of Influence Powers Одна структура не повинна одночасно контролювати весь epistemic pipeline: ```text rule creation → evidence selection → information distribution → discussion moderation → adjudication → punishment → historical record ``` Для high-impact governance ці ролі розділяються організаційно або процедурно. Мінімум: - policy author ≠ sole fact verifier; - moderator ≠ sole appellate authority; - AI recommender ≠ canonical truth authority; - data collector ≠ unrestricted political profiler; - archive operator ≠ sole editor of historical record. Жодна людина — включно із засновником Vilnism — не є `epistemic root of trust`. Символічний або історичний авторитет не створює більшої доказової ваги аргументу і не дає монополії на «справжнє тлумачення» Canon. Це є інформаційним аналогом separation of powers і доповнює §8 `Federation and anti-capture`. ### 17.13. Dependency Diversity Когнітивна свобода послаблюється, коли один центр одночасно контролює значну частину: `income + housing + identity + reputation + information + social graph + healthcare + credentials`. Тому Civilization Graph може вимірювати **structural dependency**, але не приватні переконання людини. Мета — виявляти systemic single points of dependency: - один employer; - один identity provider; - один communication provider; - один news/knowledge channel; - один critical social graph; - один operator of essential credentials. Цей layer не вимагає від кожної людини штучно мати «по три всього». Він вимагає, щоб вихід із одного вузла не означав автоматичну соціальну, економічну й інформаційну смерть. ### 17.14. Children, expertise and knowledge redundancy Освітня частина цього layer реалізується через §19 `Intergenerational Continuity Layer` і Civilization Continuity Curriculum. Дитина повинна вчитися: - питати «звідки ми це знаємо?»; - відрізняти authority від evidence; - бачити framing та false dichotomy; - працювати з probability і uncertainty; - розпізнавати рекламу та incentive structures; - перевіряти AI-generated content; - steelman-ити позицію, з якою не згодна; - змінювати висновок без сорому. Vilnism також не може викладатися як нефальсифікована доктрина. Для критичної експертизи діє `Explainability & Redundancy Rule`: - technical explanation; - accessible explanation; - independent audit; - щонайменше дві незалежні компетентні команди там, де відмова створює системний ризик; - документація; - succession / knowledge-transfer path. Експертність визнається, але не перетворюється на незаперечний політичний авторитет. ### 17.15. Sovereignty Dashboard, not Social Score Системний когнітивний ризик вимірюється на рівні інституцій і мережі, а не морального рейтингу людини. Можливі indicators: - concentration of information sources; - concentration of essential providers; - частка governance decisions із minority report; - частота emergency powers і прострочених sunset reviews; - кількість critical systems з одним knowledge holder; - algorithmic transparency coverage; - реальна cost of exit; - identity-provider concentration; - частка irreversible decisions, що пройшли objection window; - diversity of independent implementations; - частка high-impact claims із provenance та counterevidence. Заборонений один агрегований `Sovereignty Score` людини. ### 17.16. Heuristic Model Для design review допускається концептуальна, а не фізична формула: ```text Sovereignty_resilience ≈ Awareness × Diversity × Exit_Capacity × Verification × Psychological_Stability ``` Це **heuristic**, а не науково встановлене рівняння. Його сенс: критично низький рівень будь-якого компонента може різко підвищити вразливість системи навіть при сильних інших компонентах. ### 17.17. Основні об'єкти даних До Civilization Graph / governance layer додаються: - `ClaimRecord` - `EpistemicStatus` - `AlternativeModel` - `ChoiceSet` - `MinorityReport` - `SteelmanRecord` - `RedTeamReview` - `BenignExplanationReview` - `AttentionPreference` - `CognitiveSafeMode` - `CrisisEpistemicRecord` - `InfluencePowerMap` - `DependencyProfile` - `SovereigntyIndicator` AI може допомагати створювати ці records, але не має права одноосібно присвоювати людині політичну або психологічну «правильність». ### 17.18. Канонічна межа Найважливіший invariant цього layer: > **Жодний механізм захисту від маніпуляції не може отримати право визначати обов'язковий світогляд іншої людини.** Civilization OS може робити структуру впливу видимою, збільшувати число перевірок і альтернатив та зменшувати залежність від одного центру. Остаточне право сформувати висновок — разом із відповідальністю за нього — залишається у людини. ## 18. Extreme Resilience Layer Civilization OS пропонує окремий all-hazards шар: `hazard_registry → habitability_envelope → resilience_profile → drills → gaps → remediation → re-certification`. Основні сутності: - `HazardProfile` - `HabitabilityEnvelope` - `CriticalFunction` - `RecoveryTimeObjective` - `ReserveProfile` - `SkillRedundancyMatrix` - `EvacuationPlan` - `ManagedRetreatTrigger` - `MutualAidAgreement` - `ResilienceDrill` - `ResilienceEvidence` Цей шар пов'язується з Civilization Graph, Settlement Builder, VSS/VCRP, Project Marketplace і Intercommunity Protocol. AI може допомагати аналізувати ризики й планувати сценарії, але **не має права одноосібно оголошувати евакуацію, надзвичайний стан або позбавлення прав**. Заздалегідь дозволена локальна захисна дія або аварійне сповіщення не повинні чекати глобального консенсусу; межі та відповідальність визначаються чинним кризовим профілем, а наслідки проходять подальший розбір. ## 19. Intergenerational Continuity Layer Система повинна моделювати не тільки governance поточного населення, а й передачу методу між поколіннями. Мінімальні об'єкти: `CanonRevisionHistory`, `AlternativeModel`, `YouthRights`, `ExitPath`, `ForkPath`, `IntercommunityExchange`, `HistoricalFailure`, `OpenQuestion`. Жодний youth/education profile не може містити показник ідеологічної лояльності. Навчання Canon повинно включати його критику, альтернативи та процедуру зміни. ## 20. Historical Pattern Registry До Civilization Graph додається `HistoricalPattern` з полями: ```yaml id: "" source: "" evidence_class: [HIST|TEXT|MYTH|MAP|SPEC] period: "" claimed_institution: "" what_is_known: [] what_is_uncertain: [] modern_pattern: "" risks_of_literal_copy: [] testable_hypothesis: "" linked_experiments: [] ``` Registry не ранжує давні системи за «мудрістю». Його функція — перетворювати історичний матеріал у перевірювані сучасні гіпотези. ## 21. Collapse-Readable Knowledge Civilization Backup має кілька presentation levels: pictographic, basic literacy, workshop manual, engineering reference, advanced dependency tree. Критичне знання дублюється так, щоб ним можна було скористатися після втрати інтернету, сучасної освіти або частини виробничого ланцюга. --- --- ## 22. Executable Civilization Graph Починаючи з v0.5, архітектура пропонує Civilization Graph як executable dependency model для перевірки гіпотез і планування. У v0.7 цей статус залишається proposed: наявність схеми в документі не означає наявність готового engine, повних даних або перевірених технологічних ланцюгів. ### 22.1. Core node types `Resource`, `Skill`, `Tool`, `Process`, `Component`, `Device`, `Infrastructure`, `KnowledgePackage`, `Capability`, `FallbackPath`, `KnowledgeGap`, `SettlementState`, `SimulationSnapshot`. ### 22.2. Core edge types `requires`, `consumes`, `produces`, `repairs`, `maintains`, `substitutes`, `measures`, `verifies`, `teaches`, `depends_on`, `falls_back_to`. ### 22.3. Minimal technology node ```yaml id: water.potable.multibarrier kind: Capability level: L3 function: provide_potable_water requires: - resource.raw_water - process.pretreatment - process.validated_disinfection - knowledge.water_risk_limits falls_back_to: - water.potable.level2 verification: - process_integrity_check unknowns_must_remain_visible: true ``` Граф не повинен робити висновок про безпеку чи наявність capability, якщо критичний dependency невідомий або не перевірений. ## 23. Civilization Technology Stack L0–L7 Стандартні capability-рівні: - `L0 Survival` - `L1 Craft` - `L2 Mechanical` - `L3 Electrical` - `L4 Industrial` - `L5 Digital` - `L6 Autonomous` - `L7 Advanced` Рівень належить **конкретній capability-гілці**, а не всій громаді. Поселення може мати L5 digital systems і лише L2 локальне виробництво насосів. ## 24. Graceful Degradation Solver Пропонований solver має оцінювати downstream impact втрати залежності й шукати fallback paths у доступному перевіреному підграфі. Неповні дані, застарілі запаси чи відсутність компетенції залишають явну невизначеність. Алгоритмічна логіка: 1. mark unavailable dependency; 2. propagate affected capabilities; 3. search verified substitutions; 4. search lower-level fallback; 5. estimate remaining inventory/service horizon; 6. expose uncovered risks; 7. generate remediation candidates; 8. звірити operational change із чинним людським мандатом; отримати окреме рішення, якщо зміна виходить за його межі або змінює суспільну норму. UI повинен показувати різницю між `available`, `available-from-stock`, `degraded`, `unverified`, `unavailable`. ## 25. Settlement Digital Twin `SettlementState` пов'язує доступний локальний або федеративний snapshot графа з реальними даними визначеного поселення. Єдиного миттєво узгодженого глобального стану не передбачається. Для кожного запису потрібні джерело, момент спостереження, домен повноважень, актуальність і межі розкриття: - inventory and reserves; - population and skills; - machine/tools status; - power and water capacity; - maintenance backlog; - external suppliers; - spare-part horizon; - local production evidence. Мета такого представлення — обґрунтовано оцінювати питання «що ми можемо виробити зараз?», «яка функція під загрозою при втраті імпорту?», «який верстат зніме найбільше відомих обмежень?». Відповідь залежить від актуальних запасів, людей, енергії, перевірених залежностей і якості моделі; вона не гарантується структурою графа. ## 26. Simulation Reality Bridge Civilization Simulation Game має використовувати сумісну базову graph schema та працювати на окремій копії стану. Схема, результати моделювання, виміри фізичного світу й дозволені операції мають різне походження та права. ```text Real Settlement State ↓ snapshot Simulation / Game Engine ↓ stress + alternatives Failure Graph / Opportunity Graph ↓ proposals Projects / Experiments / Training ↓ evidence Updated Real Graph ``` Симуляція може працювати в трьох presentation modes: 1. **Game mode** — зрозумілий tech tree, ресурси, quests і progression. 2. **Education mode** — причинно-наслідкове пояснення «з чого зроблений світ». 3. **Operations mode** — реальні запаси, dependencies, maintenance, recovery і risk. Один data model не означає однакові права запису: ігровий прогрес ніколи не змінює реальні записи без окремої авторизованої операції. ## 27. Constitutional boundaries of the executable graph Executable Civilization Graph є інструментом опису реальності й планування, а не джерелом суверенітету. - resource scarcity не скасовує фундаментальні права автоматично; - simulation forecast не є наказом; - AI recommendation не є governance decision; - unknown залишається допустимим станом; - один aggregate «civilization score» не використовується для прав людей; - критичні технології мають відкриті dependency descriptions настільки, наскільки це сумісно з безпекою й правами; - knowledge gaps зберігаються видимими, а не заповнюються вигаданими даними. --- ## Історична примітка v0.5 У v0.5 до архітектурної пропозиції додано executable technology graph, L0–L7 capability stack, graceful-degradation solver, settlement digital twin і спільну схему reality/simulation. Ця історична примітка не засвідчує реалізацію компонентів. VSS/VCRP, Civilization Backup, Extreme Resilience та Sovereignty layers зберігають свої нормативні й безпекові межі. ## 28. WebV: локальні мережі, федерація та перевірений вихід ### 28.1. Межі шарів | Шар | Що він може визначати | Чого він не отримує автоматично | |---|---|---| | Конституція та локальне прийняття | Права, мандати, спосіб ухвалення та оскарження | Готовий код або автоматичну згоду інших громад | | WebV protocol proposal | Профілі сумісної взаємодії незалежних реалізацій | Ідеологічне членство, всесвітній реєстратор або готову wire-специфікацію | | TOS чи інший runtime | Допуск і виконання дозволених операцій у своєму домені | Право змінювати норму, чужі ліміти або локальні мандати | | Civilization OS application | Знання, моделі, договори й добровільну координацію | Політичний суверенітет над користувачами мережі | | Home, каталог, пошук | Окремо обрані навігаційні та індексні послуги | Власність на SiteID, право існування або єдину адресу мережі | | Ресурсний оператор | Договірну пропозицію обчислень, зберігання чи іншої послуги | Політичні голоси відповідно до потужності чи безстроковий доступ до даних | Нативна ідентичність WebV, ключ керування, версія контенту та маршрут до доступної копії — різні поняття. Home / ID 0 може бути домовленістю конкретного простору імен і зручною точкою входу; він не є універсальним кореневим адміністратором. Читання сторінки за прямим ідентифікатором не повинно залежати від одного каталогу. Публічна назва, ключ або підпис не доводять реальну особу, справедливість твердження чи доступність його даних. ### 28.2. Мережа та фізичні обмеження WebV проєктується для роботи поверх наявного Internet, LAN, локальних mesh-зв'язків, сумісних добровільних relay та додаткових каналів, для яких існують обладнання й правила використання. Store-carry-forward може переносити повідомлення із затримкою. Він не створює миттєвий зв'язок між фізично розділеними вузлами. Потрібні фактичний канал, живлення, носій або перенесення даних і доступний контакт. У локального острова повинні бути потрібні дані, програмні артефакти, ключі, актуальні в межах профілю мандати, ресурси, енергія та навички. Наявність протоколу не робить недоступний сервіс локальним. Для обмежених каналів визначаються пріоритети, розмір повідомлень, строки й функції, що залишаються недоступними. Відео, великий training job та remote GPU не обіцяються на вузлі лише через членство в мережі. ### 28.3. Partition і повторне з'єднання Втрата глобального зв'язку не знищує чинні локальні права й не робить worker суверенним owner. Незалежний домен може продовжувати дозволені локальні операції зі своїми даними й ресурсами. Нові дії, що потребують спільного дефіцитного права, чужого підтвердження або невідомої актуальної влади, мають зупинятися чи переходити у явно дозволений обмежений режим. Для спільних лімітів потрібен відповідний профіль: неперетинні заздалегідь виділені бюджети, чинна виключна відповідальність, підтвердження потрібних сторін або інший доведений механізм. Strong consistency, fencing та conflict-free структури мають різне застосування. Назва алгоритму не гарантує, що один фізичний ресурс не видано двічі. Fencing діє лише на межі, де приймач справді відхиляє старе повноваження; загальний журнал не замінює цю перевірку. Після відновлення каналу зберігаються походження, конфлікти й фактичні наслідки. Повторне повідомлення не повинно повторно створювати платіж, право, актуацію або списання. Найновіший timestamp не визначає законність. Невизначена операція проходить звірку чи оскарження; програмний rollback не повертає вже витрачену воду, енергію або виконану фізичну дію. Нормативні межі — §§31.9–31.11 Конституції. ### 28.4. Від bootstrap до незалежної експлуатації Перший сервер, основний сайт або засновник можуть допомогти початковому поширенню. Їхня допомога має стати замінною залежністю через передачу потрібних артефактів, реплік, маршрутів, повноважень, документації та навичок незалежним учасникам. «Критична маса» визначається здатністю конкретного профілю підтримувати функції після відмов, а не одним числом зареєстрованих людей. Відключення центрального сервера як обов'язкової залежності допускається після перевірки холодного запуску, прямої адресації, discovery без цього сервера, збереження й отримання даних, key lifecycle, локальної роботи, повторного з'єднання, експорту та зміни оператора. Перевірка має блокувати приховані дублікати тієї самої залежності. Для небезпечних сценаріїв використовуються погоджені лабораторні умови; цей документ не дозволяє вимикати робочу критичну інфраструктуру. Рішення про завершення послуги окремо враховує чинні договори, завчасне повідомлення, перенесення даних, безпечний перехід і відповідальність. Навіть після успіху exit-gates добровільні дата-центри, Home та relay можуть продовжувати надавати корисні послуги. Незалежність означає доведену замінність у визначеному профілі, а не заборону будь-яких великих серверів. ### 28.5. Відновлення прав та ідентичності Профіль визначає створення, ротацію, відкликання, відновлення та завершення дії ключів; окремо — вирішення суперечливих заяв про керування. Особистий recovery є добровільним і не передає громаді універсальний ключ до приватного життя. Інституційні порогові повноваження мають реальне розділення контролю. Під час partition неможливо вважати невідоме відкликання гарантовано отриманим: обсяг ризику обмежується строками, бюджетами, локальним зупиненням і профілем звірки. Втрата ключа, пристрою або мережі не скасовує базові людські права. Людська чи паперова процедура може відновити правовий статус згідно з прийнятою нормою; вона не відтворює втрачений секрет і не гарантує розшифрування старих даних. Оновлена довіра має власне походження та видиму невизначеність. ## 29. Статус гарантій і докази | Вимога або можливість | Нормативна опора | Статус механізму в цьому companion | Runtime-перевірка цього релізу | |---|---|---|---| | Розділення публікації, прийняття та виконання | §§16–19, 36 | PROPOSED; реалізація звіряється окремо | NOT_RUN | | Незалежні реалізації WebV та замінні точки входу | §§36, 49.10–49.12 | PROPOSED; wire-профіль потребує окремого погодження | NOT_RUN | | Контроль персональних ключів і recovery | §§34.8, 34.15–34.19 | PROPOSED; метод і загрози фіксуються в профілі | NOT_RUN | | Локальна автономія без подвійних ефектів | §§19.8, 31.9–31.11, 49.14 | PROPOSED; класи операцій мають різні обмеження | NOT_RUN | | Добровільні ресурси, межі й відповідальність | §§19.7, 32.14, 40.8 | PROPOSED; потрібні конкретні договори й budget guards | NOT_RUN | | AI у межах мандата та дозволений Genesis | §20 | PROPOSED; перевіряються parent limits і реальне припинення | NOT_RUN | | Solver, Digital Twin та фізична придатність | §§19, 35–36 | PROPOSED; потрібні дані, verifier, польова перевірка | NOT_RUN | | Відключення обов'язкового bootstrap та відновлення | §§49.16–49.19 | PROPOSED; застосовуються окремі exit-gates | NOT_RUN | Конституційна вимога залишається вимогою навіть там, де механізм ще не реалізовано. Вона не є доказом її виконання. Звіт повинен містити точні версії, обладнання, конфігурацію мережі, модель загроз, незалежність учасників, умови відмови, фактичні результати, відомі прогалини та межі перенесення висновку. Hash доводить збіг байтів за відповідних припущень; signature пов'язує повідомлення з ключем. Правомочність, істинність, фізична безпечність, справедливість і доступність оцінюються окремо. Специфікація перевірок **WEBV_CONFORMANCE_AND_EXIT_PROTOCOL v0.2** містить E01–E16. Наявність цього плану не означає їх проходження. NOT_RUN або BLOCKED не підмінюється PASS. Схвалення документа, перевірка структури сайту, simulation trace і випробування реального runtime мають різні предмети доказування. ## Зміни v0.7 та джерела узгодження Ця версія зберігає концептуальний зміст v0.6, уточнює його статус і межі, розводить протокол та реалізації, додає локальні острови, key lifecycle, обмежене делегування, добровільні ресурси й профільні докази незалежності. v0.6 збережено як історичний файл. Історичне дублювання нумерації усунуто лише у v0.7: | Розділ v0.6 | Розділ v0.7 | |---|---| | Перші §§1–16, до «Довгострокова теза» включно | §§1–16 без перенумерації | | Другий §13 «Cognitive & Systemic Sovereignty Layer» | §17 та підрозділи 17.1–17.18 | | Другі §§14–16: Extreme Resilience, Intergenerational Continuity, Historical Pattern Registry | §§18–20 | | §§17–23: Collapse-Readable Knowledge — Constitutional boundaries | §§21–27 | | Нові WebV та evidence sections | §§28–29 | Джерела узгодження: - [Constitution chapters](../canon/chapters/): Canon corpus v0.17.0 / Foundation v0.15.0, status review; фактичне прийняття встановлюється окремо. - [WebV Architecture and Mission v0.2](../research/web_v/VILNISM_WEB_V_ARCHITECTURE_AND_MISSION_v0.2_uk.md): цілі, шари, відкриті рішення, межі мережі та первинні технічні джерела. - [WebV Conformance and Exit Protocol v0.2](../research/web_v/WEBV_CONFORMANCE_AND_EXIT_PROTOCOL_v0.2_uk.md): вимоги до доказів E01–E16, усі виконання цього пакета NOT_RUN. - TOS / WebV Resource Router Roadmap Addendum v1.0.0, 2026-10-30: профілі resource graph, execution, sovereignty, network, AI/Genesis та термінологія, описані у джерелах WebV v0.2. Roadmap є джерелом задуму, а не підтвердженням реалізації.