Архитектура системы

Noosphere — это инфраструктура для коллективных решений, в которой голосование взвешивается по качеству продемонстрированной аргументации, а не по размеру стейка токена. Архитектурно это сочетание блокчейна (для неподделываемой фиксации решений и транзакций), типизированного графа аргументации (для представления коллективного мышления) и плюралистичного слоя AI-инфраструктуры (для оценки, перевода, индексации и работы с графом) — при условии, что каждое решение AI оспоримо тем же механизмом, что и любое другое утверждение в системе, и что выбор конкретной AI-модели для работы остаётся за участником.

Этот документ описывает архитектуру системы. Назначение, область применения и обоснование подхода изложены в отдельном документе.

Три архитектурных тезиса, которые объясняют, в какой рамке существует система:

Первый. Сеть, устойчивая к захвату, устроена не как реестр, а как граф связей участников с привязанными к ним PoI-профилями. Захват реестра оставляет пустую оболочку — участники переходят в форк. Право на форк — структурная защита.

Второй. Sybil-устойчивость — эмерджентное свойство пересечения слоёв, а не одного текстового. Множество пустых аккаунтов даёт множество нулей в формуле веса; но качество аргумента подтверждает только сам аргумент, не уникального человека за ним. Идентификация (уникальный непринуждённый участник), экономический предел влияния с обесцениванием захвата через форк и живой экспертный peer-review замыкают то, что текстовый слой в одиночку больше не держит. Атака требует одновременного пробоя всех слоёв — и по стоимости снова сходится к легитимному участию.

Третий. AI-инфраструктура плюралистична и оспорима: ни одна модель не определяет финальный результат, каждое её суждение становится частью графа и может быть оспорено тем же механизмом, что и любое утверждение.

Архитектура решает класс задач, который недостаточно покрывается моделями one-token-one-vote: коллективные решения, где вес голоса должен определяться качеством аргументации, а не размером стейка; где аргументация типизирована и неотделима от голосования; где каждое решение системы оспоримо; где устойчивость к захвату обеспечивается структурно (право на форк), а не надеждой на дороговизну атаки; где идентичность верифицируется через демонстрируемое мышление, а не через документы; где AI-инфраструктура плюралистична. Эти требования формализованы ниже как восемь архитектурных принципов.

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

2.1. Argument over stake

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

Это решает фундаментальную проблему DAO-моделей one-token-one-vote: невозможность принципиально отделить право голоса от размера капитала. В Noosphere право голоса зарабатывается через демонстрацию мышления; капитал может усиливать вес уже заработанного голоса, но не может заменить его отсутствие.

Архитектурное следствие: основной вес в формуле голоса даёт PoI Score (Proof of Intelligence) — оценка качества аргументации участника. Стейк входит в формулу под корнем и с потолком (SphereCap), что делает увеличение капитала всё менее эффективным.

2.2. Contestability of all infrastructure

Каждое решение системы оспоримо через стандартный механизм аргументации. Это относится не только к голосованиям по содержательным вопросам, но и к решениям инфраструктурного уровня — кластеризации позиций, оценкам качества аргументации, переводам, PoI-калибровке. В том числе и особенно — к решениям AI-компонентов.

Архитектурно это означает, что AI в системе не имеет привилегированной роли финальной инстанции. AI делает первоначальное предложение (быстрее людей, дешевле, в реальном времени), но это предложение становится частью графа аргументации и может быть оспорено любым участником через тот же механизм, что и любое содержательное утверждение. Разрешение спора происходит через PoI-взвешенное голосование, в котором решения AI имеют такой же статус, как и аргументы людей.

Это принципиально отличает архитектуру от стандартных AI-powered систем, где AI — финальная инстанция, а пользователь либо принимает решение AI, либо нет, но не может содержательно его оспорить внутри системы.

2.3. Multilingualism as architectural condition

Ни один язык не привилегирован в системе. Это не "поддержка нескольких языков как функция", а архитектурное условие.

Каждое утверждение в графе хранится в оригинальной языковой версии — той, на которой автор его создал. Оригинал никогда не замещается переводом; перевод — отдельный объект в графе со своим автором (человеком или AI), своим PoI-весом автора перевода, своей историей контестации. На один оригинал может существовать несколько конкурирующих переводов на тот же целевой язык, каждый из которых может быть оспорен через стандартный механизм.

Архитектурное следствие: тип связи Translation равноправен типам Argument и Endorsement в графе. Translation — это форма утверждения о тождественности смысла между двумя текстами на разных языках, и это утверждение оспоримо.

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

2.4. Fork as capture defense

Право на форк Сферы — структурная защита от любой попытки её захвата, включая попытку самой команды Noosphere.

Сфера в Noosphere устроена не как реестр (запись в системе, которую можно захватить, изменив запись), а как сеть связей между участниками с привязанными к ним PoI-профилями и аргументационным графом. Захват реестра — в случае, если кто-то получит контроль над метаданными Сферы — оставляет пустую оболочку: участники со своими PoI-профилями переходят в форк, унося с собой реальное содержание Сферы (граф аргументации, репутацию, доверие участников друг к другу).

Это меняет экономику атаки. Захват реестра без захвата участников бесполезен; захват участников требует их добровольного согласия следовать в захваченную Сферу, что в случае враждебного захвата маловероятно.

Архитектурное следствие: механизм форка — это первоклассная функция системы, доступная участникам по голосованию внутри Сферы, а не редкое чрезвычайное действие.

2.5. On-chain what matters, off-chain what scales

Архитектура использует явное разделение: что критично для неподделываемости — лежит на цепи (Solana), что необходимо для масштабируемости и удобства работы — лежит вне цепи, но с криптографической связью с он-цепи.

На цепи: хэши узлов графа, голосования и их результаты, реестр участников и их PoI-профили, казна Сферы, multisig-управление исполнением, ключевые события (создание Сферы, форк, закрытие).

Вне цепи: полные тексты аргументов (IPFS для активного контента, Arweave для permanent storage важных финализированных артефактов), индексы графа (Neo4j или Dgraph), поисковая инфраструктура, UI-уровень.

Криптографическая связь: каждый узел и каждая связь имеют хэш, записанный на цепи. Подмена off-chain содержимого делает невозможным его сопоставление с on-chain хэшем и автоматически детектируется.

2.6. Spheres as networks, not registries

Это переформулировка принципа 2.4 в его архитектурном измерении. Sphere в Noosphere определяется множеством её участников и их связями (общим аргументационным графом, общей казной, общей историей голосований), а не записью в едином реестре.

Архитектурное следствие: нет единого "центра", контроль над которым означает контроль над Сферой. Метаданные Сферы (название, описание, параметры) хранятся на цепи и могут быть оспорены или изменены через голосование участников Сферы. Захват любой одной точки — серверов, узла, метаданных, ключей — не равен захвату Сферы.

2.7. AI as participant, not authority

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

Каждый раз, когда AI делает суждение — оценивает PoI участника, классифицирует аргумент, предлагает перевод, выявляет паттерн в графе — это суждение является видимым предложением, оспоримым тем же механизмом, что и любое утверждение в системе. Если участник считает оценку AI неверной, он формулирует контраргумент через стандартный механизм, и спор разрешается PoI-взвешенным голосованием.

Это не означает, что каждое решение AI обязательно оспаривается — большинство пройдёт без спора, потому что будет адекватным задаче. Но архитектурная возможность оспаривания меняет статус AI: он перестаёт быть финальной инстанцией и становится высокопроизводительным, но процедурно проверяемым участником.

2.8. AI Pluralism

Не одна AI-модель работает в системе как часть инфраструктуры — а множественность моделей, выбираемых участниками. Каждый участник определяет, какая модель помогает ему работать с графом, ранжирует для него аргументы, делает переводы, предлагает классификации.

Это завершение принципа AI as participant: если AI — участник, то невозможно, чтобы был единственный AI. Каждый человек-участник выбирает себе AI-партнёра, и расхождение между видением графа через разные модели становится видимым и обсуждаемым.

Архитектурное следствие: стандартизированный интерфейс Noosphere AI Layer, через который любая модель может быть подключена — облачные API (Claude, GPT, Gemini, Mistral), локальные модели на устройстве участника (через Ollama, llama.cpp), децентрализованные инференс-сети (Bittensor, Ritual). Noosphere экономически нейтральна к выбору AI — участник платит за инференс напрямую провайдеру или платформе, без посредничества Noosphere.

Это устраняет последнее место скрытой централизации в системе: AI-уровень.

В этой части описаны основные компоненты системы. Каждый компонент рассматривается с указанием конкретных технологий, на которых он реализуется, и явных архитектурных развилок там, где они есть.

3.1. Argumentation Graph

Структура коллективного мышления в Noosphere представлена как направленный ациклический граф (DAG) с типизированными узлами и связями.

Типы узлов:

• Claim — утверждение. Базовая единица содержания. Утверждение о факте, ценности, прогнозе, предложении.

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

• Endorsement — поддержка существующего утверждения или аргумента без создания нового. Менее тяжеловесная форма участия, чем создание полноценного аргумента.

• Translation — утверждение о тождественности смысла между двумя текстами на разных языках. Самостоятельный тип узла, потому что перевод сам по себе является оспоримым утверждением.

Типы связей между узлами:

• SUPPORTS — A поддерживает B. Аргумент поддерживает утверждение.
• REBUTS — A опровергает B. Контраргумент против утверждения или другого аргумента.
• UNDERCUTS — A подрывает связь между C и D, не атакуя ни C, ни D напрямую. Атака на обоснование, не на утверждение.
• QUALIFIES — A уточняет применимость B, ограничивая область, в которой B справедливо.

Ограничения: циклы в графе не допускаются по определению (это DAG). Связь Translation — особый случай, не образующий типичных циклов, потому что соединяет узлы на разных языках, представляющие тождественное содержание.

Хранение:

• On-chain (Solana): хэш каждого узла и каждой связи, метаданные (автор-кошелёк, временная метка, тип), PoI-вес автора на момент создания.
• Off-chain: полный текст узлов в IPFS для активного контента и в Arweave для финализированных значимых артефактов; структура графа в Neo4j (предпочтительный выбор) или Dgraph.

Криптографическая связь между слоями: хэш полного текста (включая язык оригинала и метаданные) записывается на цепи в момент создания узла. Любая подмена текста вне цепи делает хэш несовпадающим и автоматически детектируется.

Открытый вопрос (Часть 5): конкретная стратегия гибрида IPFS/Arweave для разных классов содержимого, с учётом стоимости и долгосрочной надёжности.

3.2. PoI Score (Proof of Intelligence)

PoI Score — это оценка качества демонстрируемой участником аргументации. Это не reputation score в обычном смысле (не количество лайков, не социальный рейтинг), а оценка по пяти структурным критериям, применяемая к реальной аргументационной активности участника.

Пять критериев:

• Argument structure — насколько ясно сформулирован тезис, насколько чётко отделены посылки от выводов, насколько корректна логическая структура.

• Depth of knowledge — насколько глубоким знанием темы демонстрирует участник в своих аргументах. Не "знает много фактов", а "понимает контекст и его сложность".

• Handling of counterarguments — как участник реагирует на контраргументы. Игнорирует, переходит на личности, отвечает поверхностно — низкий балл. Признаёт сильные места противоположной позиции, уточняет свою позицию, опровергает по существу — высокий.

• Cognitive patterns — устойчивые паттерны мышления, видимые в аргументации. Различение причины и корреляции, осознание ограничений своей позиции, способность держать сложность.

• Clarity of expression — насколько ясно выражена мысль. Это не литературное мастерство, а коммуникативная ясность.

Два режима оценки:

• Общий ongoing профиль: накопительная оценка по всей аргументационной активности участника в системе, с временным взвешиванием (недавняя активность весит больше).

• Pre-vote assessment: целевая оценка PoI участника применительно к конкретной теме голосования, проводимая непосредственно перед важными решениями. Учитывает специфику темы и компетентность участника в ней.

Калибровочный диалог: первичная оценка PoI происходит через структурированный диалог с AI-компонентом системы. Диалог намеренно проектируется как длинный, разветвлённый, с уточняющими вопросами. Сам по себе текстовый обмен не несёт sybil-нагрузку — сильную аргументацию LLM генерирует на лету; нагрузку несёт связка калибровки с остальными слоями (см. 3.6): идентификационным (диалог привязан к уникальному непринуждённому участнику) и социальным (спорные случаи уходят в живой экспертный peer-review, плохо воспроизводимый LLM-прокси). AI-модель для калибровки выбирается участником из доступных в системе (см. Часть 3.8 о AI Pluralism), но фиксируется на момент калибровки для воспроизводимости.

Формула веса голоса:

weight = (PoI_user / avg_PoI_sphere) × √(min(staked_NOS, SphereCap))

Где:

• PoI_user — текущий PoI Score участника
• avg_PoI_sphere — средний PoI Score участников Сферы
• staked_NOS — количество $NOS, застейканных участником в данном голосовании
• SphereCap — потолок стейка, устанавливаемый каждой Сферой отдельно

Первая часть формулы (отношение к среднему PoI Сферы) — против анонимных аккаунтов с нулевой историей мышления. Их вес близок к нулю, независимо от размера стейка.

Вторая часть (корень из стейка, ограниченный SphereCap) — против чисто капитальной атаки. Корень и потолок делают увеличение капитала всё менее эффективным.

Контестируемость PoI-оценок: каждая оценка PoI — это решение AI-компонента, и оно может быть оспорено через стандартный механизм. Участник, считающий, что его PoI оценён неверно, формулирует аргумент через тот же механизм, и спор разрешается peer review плюс PoI-взвешенным голосованием.

Peer review: в спорных случаях оценка PoI верифицируется через живой диалог участника с экспертом по теме, верифицированным в Сфере. Это не review транскрипта, а реальный двусторонний разговор, в ходе которого эксперт оценивает мышление участника.

Открытый вопрос (Часть 5): защита калибровочного диалога от prompt injection и от прохождения калибровки через LLM-прокси, оптимизированный под scoring-промпт, — то есть какая доля спорных случаев должна принудительно уходить в идентификационный и социальный слои.

3.3. Sphere Lifecycle

Sphere — это коллективный субъект, объединённый общей казной, общим аргументационным графом, общими правилами голосования. Она имеет жизненный цикл.

Создание: Сфера создаётся инициирующей группой участников (порог количества и совокупного PoI устанавливается на уровне протокола). При создании задаются параметры: название, описание (само по себе является утверждением, оспоримым после создания), начальный SphereCap, базовые правила голосования.

Регулярная работа: участники предлагают утверждения, формулируют аргументы и контраргументы, голосуют по решениям. Все артефакты — на цепи (хэши) и вне цепи (полные тексты). Решения Сферы исполняются через эскроу-механику и multisig.

Эскроу и целевые траты: Сфера может голосовать о трате $NOS на конкретную цель. Средства резервируются в эскроу, освобождаются по завершении цели (с подтверждением выполнения), возвращаются в казну при неисполнении.

Форк: любой участник Сферы может инициировать форк. Форк создаёт новую Сферу с тем же аргументационным графом, той же истории голосований, теми же PoI-профилями участников. Казна разделяется пропорционально (правило разделения устанавливается изначальной Сферой). Участники самостоятельно решают, в какой из двух Сфер продолжать участвовать. Право на форк работает как структурная защита от любых попыток захвата.

Закрытие: Сфера может быть закрыта по голосованию участников. История остаётся на цепи навсегда; казна распределяется по правилу, заданному изначальной Сферой.

3.4. Казна и финансовые механизмы

$NOS — внутренняя функциональная валюта Noosphere. Не спекулятивный актив; цель её существования — обеспечивать механизмы внутри системы.

Функции $NOS:

• Стейк в голосованиях: участник стейкает $NOS, выражая обязательство и заинтересованность. Стейк входит в формулу веса голоса.

• Эскроу под целевые траты: казна Сферы держит $NOS, выделяемый по голосованию на конкретные цели.

• Инвестиции в проекты Сферы: участники могут инвестировать $NOS в конкретные инициативы внутри Сферы, получая долю в результатах (если применимо). Это создаёт публичную, неподделываемую историю инвестиционных решений каждого участника.

Три слоя репутации (все on-chain, публичные):

• PoI Score — качество аргументации.
• Peer Review track record — история экспертных оценок: на каких peer review был участник, в качестве кого, с каким результатом.
• Investment/Contribution History — публичная история инвестиций и взносов в проекты внутри Сфер.

Эти три слоя независимы, но видимы вместе. Они не сводимы к единому числу — каждый показывает разную сторону репутации.

Multisig исполнения: для исполнения мандата Сферы в офф-чейн действиях используется multisig — распределённая подпись нескольких держателей. Держатели подписей назначаются голосованием Сферы, распределены географически, обязаны исполнять решения Сферы. Невыполнение мандата — основание для отзыва ключа через голосование Сферы.

3.5. Contestability Layer

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

Что может быть оспорено:

• Оценка PoI конкретного участника
• Перевод аргумента на другой язык
• Кластеризация позиций, предложенная AI
• Классификация связи между узлами графа
• Параметры протокола (через голосование)
• Архитектурные решения команды разработки (через предложения с PoI-взвешенным голосованием)
• Результаты любой конкретной AI-модели (с возможностью сравнения с другими моделями — см. Часть 3.8)

Как работает оспаривание:

• Участник формулирует контраргумент к оспариваемому решению через стандартный механизм Argument с типом связи REBUTS или UNDERCUTS.
• Контраргумент включается в граф наряду с другими утверждениями.
• Возникает локальный спор: оригинальное решение vs контраргумент. Другие участники могут поддерживать одну или другую сторону через свои аргументы.
• Спор разрешается PoI-взвешенным голосованием. Если контраргумент побеждает — оригинальное решение пересматривается. Если проигрывает — остаётся в силе, но контраргумент остаётся в записи как фиксированная попытка оспаривания.

Что это меняет: AI и команда разработки имеют только то влияние, которое позволяет им PoI-взвешенное голосование участников. Они не могут навязать решение, обходя механизм аргументации.

3.6. Identity and Sybil Resistance

Архитектура Noosphere не требует KYC. Идентичность участника — это его кошелёк, привязанный PoI-профиль и история активности в системе.

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

Sybil-устойчивость через PoI: создание дополнительных кошельков не даёт преимущества, потому что каждый новый кошелёк имеет нулевой PoI и должен набирать его через демонстрацию мышления. Множество пустых аккаунтов даёт множество нулей в формуле веса.

Sybil-устойчивость как пересечение слоёв: ранние формулировки атрибутировали устойчивость семантическому слою — допущению, что качественную аргументацию нельзя произвести в масштабе без соответствующего числа компетентных людей. С появлением дешёвой генерации текста это допущение более не самодостаточно: модель производит сильную аргументацию в объёме, ограниченном лишь вычислительным ресурсом, и может быть оптимизирована против известного scoring-промпта. Устойчивость сохраняется, но как эмерджентное свойство пересечения четырёх слоёв, ни один из которых не несёт нагрузку в одиночку.

• Семантический слой оценивает качество аргумента (структура, глубина, работа с контраргументами, когнитивные паттерны, ясность), но подтверждает свойство текста, а не наличие человека за ним.

• Идентификационный слой (The Node: биометрия плюс coercion-resistance) подтверждает уникального непринуждённого участника, но не источник текста.

• Экономический слой (предел влияния на одного участника, публичная инвестиционная история, право форка) ограничивает вес независимо от качества аргументации: захват не масштабируется выше предела влияния и обесценивается форком.

• Социальный слой (peer-review как живой экспертный диалог в реальном времени, рекуррентность PoI) опирается на латентность, импровизацию и перекрёстные уточнения, плохо воспроизводимые LLM-прокси при участии человека-посредника.

Атака требует одновременного пробоя всех четырёх слоёв: уникального непринуждённого человека, самостоятельно ведущего экспертный диалог на уровне высокого PoI, в количестве выше предела влияния. По совокупной стоимости это снова сходится к легитимному участию, а не к атаке.

Hardware-уровень в долгосрочной перспективе: идентификационный слой в наиболее строгой форме реализуется через опциональный hardware-уровень (The Node) — устройство с LiDAR для coercion-resistance, обеспечивающее повышенную защиту в особо чувствительных голосованиях. Это не обязательное условие участия в системе, а усиление идентификационного слоя для голосований, требующих повышенной защиты от принуждения.

Coercion-resistance как класс задачи: защита от принуждения — это не binary flag (защищено / не защищено), а класс задачи, который можно решать с разной степенью строгости. Архитектура должна повышать стоимость атаки класса "силовик у виска 30 секунд" до уровня сложности, неприемлемого для массового применения.

3.7. Argumentation Interaction Layer

Этот раздел описывает, как устроено взаимодействие участника с графом аргументации в момент работы — что происходит, когда участник пишет новое утверждение, и как он работает с уже существующим графом.

Что происходит, когда участник пишет

В момент написания нового утверждения AI-компонент в реальном времени делает три параллельные операции:

• Семантический поиск по существующему графу. Текст преобразуется в эмбеддинг и сравнивается с эмбеддингами существующих узлов. Поиск работает мультиязычно — близкий по смыслу аргумент на украинском найдётся при запросе на русском.

• Классификация типа утверждения. AI определяет, что именно человек собирается сказать: новый Claim, поддержка существующего, опровержение, уточнение, переформулирование.

• Построение карты релевантного фрагмента графа. AI находит не только похожие аргументы, но и их контр-аргументы, поддерживающие линии, успешные опровержения. Получается локальная карта дискуссии по теме.

Что показывается участнику

Три блока информации:

• Блок 1: "Похожие утверждения уже в Сфере". Список из 3-5 близких по смыслу аргументов, отсортированных по семантической близости и PoI-весу авторов. Для каждого — короткое резюме, сколько раз он был поддержан, есть ли успешные контраргументы.

• Блок 2: "Структура дискуссии по этой теме". Визуализация того, как уже разветвлена аргументация: основные линии, основные контраргументы, узлы с наибольшей поддержкой.

• Блок 3: "Возможные действия". AI предлагает участнику явные варианты того, что он может сделать.

Шесть вариантов действий:

• Endorse существующее утверждение — поддержка без создания нового узла, PoI-вес участника добавляется к существующему.

• Sign on with addition — поддержка с уточнением, создание нового узла с типом связи QUALIFIES или SUPPORTS к существующему.

• Restate in another framing — добавление альтернативной формулировки той же позиции с явной связью равноценности.

• Contest with REBUTS or UNDERCUTS — если AI определил, что участник возражает против существующего, предлагается явное контр-возражение.

• Create new Claim/Argument — создание полноценного нового узла, с предупреждением о близких существующих.

• Ask for clarification — если формулировка двусмысленна, AI просит участника уточнить, что он имеет в виду.

Принципы работы:

• Решение участника записывается. Если AI предложил классификацию, а участник её игнорировал — этот выбор фиксируется, и при систематическом игнорировании AI-подсказок PoI участника по критерию "argument structure" страдает.

• Подсказки AI оспоримы. Это применение принципа Contestability: если участник считает, что его аргумент существенно отличается от похожего — это формальное возражение, фиксируемое в записи.

• Контроль остаётся за участником. AI ни в каком случае не запрещает создание нового узла. Финальное действие — за человеком.

Связь с PoI Score: участник, который умеет правильно встраивать утверждения в существующий граф — поддерживать там, где согласен, контестировать там, где не согласен, видеть структуру — демонстрирует высокий уровень мышления. PoI по критерию "handling of counterarguments" растёт. Участник, который игнорирует структуру и плодит шум — теряет в этом критерии.

Множественность представлений графа

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

• Режим 1: AI-curated. AI определяет, что показать первым, как кластеризовать, какие аргументы выделить. Использует все доступные ему сигналы. Режим по умолчанию для нового пользователя.

• Режим 2: Human-curated. Сортировка только по явным человеческим действиям — количество Endorsement (взвешенное PoI эндорсеров), успешность в peer review, результаты голосований. AI не влияет на порядок.

• Режим 3: Hybrid. Комбинация двух предыдущих с настраиваемым весом, по умолчанию 50/50.

• Режим 4: Chronological. Хронологический порядок без сортировки по содержанию.

Плюс — фильтры: по языкам (только оригиналы на определённых языках или включая переводы), по типу узлов (только Claim, только Argument), по PoI-весу автора (минимальный порог), по времени.

Принципы множественности представлений:

• Сохранение пользовательских настроек. Выбор режима сохраняется как часть профиля участника.

• Прозрачность того, что показывается. В любом режиме участник видит метку, объясняющую сортировку: "AI-curated, hybrid 70/30, фильтр: только оригиналы на русском, минимальный PoI автора 50".

• Сравнение режимов в одно действие. Возможность одной кнопкой посмотреть, как тот же фрагмент графа выглядит в другом режиме.

• Запись статистики выбора режимов. Статистика того, какие режимы выбирают участники в какой Сфере — публичная информация. Расхождение между AI-сортировкой и Human-сортировкой само по себе содержательно ценно.

• Контестируемость самих режимов. Если участник считает, что AI-сортировка в Сфере систематически смещена — он может формально оспорить это через стандартный механизм.

Открытые вопросы (Часть 5): точная балансировка склейки vs нюанса при семантическом поиске; формализация порога семантической близости; визуальный дизайн переключения между конкурирующими переводами в UI.

3.8. AI Pluralism Layer

Архитектурный слой, через который любая AI-модель может быть подключена к работе с Noosphere. Это место, где принцип AI Pluralism (Часть 2.8) воплощается технически.

Стандартизированный интерфейс Noosphere AI Layer

Чтобы любая модель могла быть подключена, существует формальный API, описывающий, что AI должен уметь делать в системе:

• Ранжировать узлы графа (для AI-curated режима представления)
• Делать семантический поиск (мультиязычный)
• Классифицировать утверждения (определение типа предполагаемой связи)
• Оценивать PoI по пяти критериям (для калибровочного диалога и для непрерывной оценки)
• Делать переводы (как первую итерацию, оспоримую другими переводами)
• Кластеризовать позиции (для агрегированного представления Сферы)

Каждая модель реализует этот интерфейс через wrapper для коммерческих API, через локальный сервер для opensource моделей, через узел децентрализованной инференс-сети. Wrapper'ы развиваются как opensource модули в репозитории Noosphere.

Уровни подключения моделей

• Облачные API (Claude, GPT, Gemini, Mistral, и другие): через ключ API, предоставляемый участником. Участник платит за инференс напрямую провайдеру.

• Локальные модели на устройстве участника: через Ollama, LM Studio, llama.cpp. Бесплатно для участника, но требует мощного компьютера.

• Децентрализованные инференс-сети (Bittensor, Ritual, Akash): оплата в крипте, без централизованного провайдера. Идеологически согласовано с проектом.

• Дефолтный AI Сферы: для участников, не настроивших собственный, Сфера может предоставлять базовую модель за оплату в $NOS, как сервис. Этот дефолт сам по себе оспорим Сферой — какая именно модель является дефолтной, решается голосованием.

Прозрачность того, какая модель работает

В UI всегда видно, какая модель производит конкретный результат: "Ранжировано: Claude Sonnet 4.7", "Перевод предложен: GPT-5", "Семантический поиск: Llama 3 локально". Это критично для понимания участником, что он видит, и для оспаривания: если несколько участников видят разную картину, потому что используют разные модели, расхождение должно быть атрибутировано.

Контестация результатов между моделями

Если разные модели дают разные результаты — это нормально, но видимо и оспоримо. Если Claude ранжирует аргумент X высоко, а GPT — низко, и это значимо для понимания Сферы — участники могут зафиксировать расхождение как явление и обсудить через стандартный механизм аргументации. Это новый класс мета-аргументации: не "X правильный или нет", а "разные AI оценивают X по-разному, что это означает".

Кэширование и воспроизводимость

Результаты работы конкретной модели на конкретных входных данных кэшируются: хэш входа плюс модель плюс результат, всё с временной меткой. On-chain записывается хэш кэш-записи; off-chain — полный результат. Это обеспечивает воспроизводимость — другой участник, говорящий "Claude ранжирует так-то", может сослаться на конкретную кэш-запись, и любой третий участник видит тот же результат.

Экономическая нейтральность Noosphere

Noosphere не берёт комиссию с инференса и не контролирует поток денег к AI-провайдерам. Это принципиально: если бы Noosphere получала комиссию с использования AI, у неё был бы стимул продвигать конкретные модели или подавлять другие. Нейтральность экономики делает выбор AI действительно свободным.

Качество модели влияет на её использование

AI-модели сами подвержены оспариванию через PoI-механику. Если модель систематически даёт плохие результаты — она получает низкий PoI как участник системы. Со временем участники не выбирают её, и она выпадает из активного использования. Это создаёт стимул для AI-провайдеров улучшать качество работы их моделей в контексте Noosphere, а не просто маркетировать их.

Защита от манипуляции через выбор AI

Возможна атака: участник выбирает модель, заведомо предвзятую в нужную ему сторону. Защита: выбор модели не влияет на голосование напрямую. Голосование взвешивается PoI и стейком, не AI-помощью. AI работает на уровне представления и подсказок, но не на уровне формального веса. Участник, смотрящий на Сферу через предвзятый AI, имеет такой же вес голоса, как и работающий с другой моделью.

Эволюция интерфейса

Noosphere AI Layer сам версионируется. По мере развития AI-технологий (рассуждение, агентная работа, новые модальности) интерфейс может расширяться. Развитие интерфейса — решение Сферы через стандартный механизм аргументации, не решение команды разработки.

Открытые вопросы (Часть 5): конкретный формат стандартизированного API; механизм валидации wrapper'ов для новых моделей; экономика "дефолтного AI Сферы" — кто платит за инференс, когда участник не настроил собственный AI.

Дорожная карта состоит из нулевого подготовительного этапа (инфраструктурный минимум) и последующих технических этапов, каждый с явными критериями завершения. Следующий этап не открывается, пока критерий предыдущего не выполнен. Это не сроки в календарном смысле — это последовательность с проверяемыми условиями перехода.

Этап 0. Инфраструктурный минимум и базовая защита

Технический MVP с тремя тестовыми Сферами работает на Solana. Multisig исполнения развёрнут и распределён между 5-7 держателями. PoI-калибровка проходит полный цикл для минимум 50 тестовых участников. Все артефакты on-chain и верифицируемы. Мультиязычная архитектура проверена в реальном использовании (минимум один аргумент с переводом, минимум одна контестация перевода). Контестируемость AI-инфраструктуры проверена (минимум одна успешная контестация). Базовая версия Noosphere AI Layer работает с минимум двумя моделями (одной облачной и одной локальной).

Этап 1. Первое содержательное голосование

Первое содержательное голосование Сферы — о механизме распределения комиссий внутри протокола. Цель этапа — проверка механизма под нагрузкой реального решения с реальными последствиями. Голосование проходит полный цикл, решение технически имплементируется в протоколе, все этапы документируются on-chain. Выловлены и зафиксированы баги PoI-калибровки и голосования. Минимум 200 участников прошли калибровку. Аргументация прошла минимум на двух языках с работающей контестацией переводов.

Этап 2. Сферы внутренних решений

Запуск Сфер по внутренним вопросам проекта — приоритеты разработки, распределение бюджета, выбор инфраструктурных партнёров. Реальные траты с реальными деньгами. Минимум три цикла "голосование → трата средств → отчёт об исполнении". Работающий механизм публикации финансовых отчётов. Минимум 1000 участников в системе. Право на форк проверено хотя бы одним учебным форком. Подтверждено: траты от имени Сферы исполняются через multisig по результату голосования. Noosphere AI Layer поддерживает минимум четыре модели разных типов.

Этап 3. Масштабирование числа Сфер

Открытие Сфер по произвольным доменам сторонними инициаторами. Снижение порога создания Сферы до уровня, при котором право на выход (форк) реально. Отработка inter-Sphere взаимодействия: перенос репутации между Сферами, цитирование решений, координация. Нагрузочное тестирование индексации графа и семантического поиска на возросшем объёме. Стабилизация PoI-калибровки на разнородной аудитории. Критерий завершения: устойчивая работа при минимум десяти параллельных активных Сферах с независимыми параметрами SphereCap.

Этап 4. Собственный testnet

Запуск собственного testnet Noosphere Protocol с PoI как нативным элементом консенсуса — вес валидатора зависит от его PoI наряду со стейком. Перенос принципа argument over stake с уровня приложения на уровень протокола. Параллельная работа Solana и testnet, отработка миграции графов и репутации между ними. Критерий завершения: тестовая Сфера полностью функционирует на собственном testnet, включая голосование, граф и казну.

Этап 5. Децентрализация инференса и hardware-уровень

Перевод AI Layer на децентрализованные инференс-сети как полноценную опцию наравне с облачными API и локальными моделями. Открытие спецификации The Node, дев-кит, выпуск первого тиража узловых устройств с опциональной функцией coercion-resistance. Критерий завершения: значимая доля инференса проходит через децентрализованные сети; работающие физические узлы в руках участников.

Этап 6. Mainnet

Запуск mainnet Noosphere Protocol. Существующие на Solana Сферы мигрируют со своими графами и репутацией. Критерий завершения: основной объём активности перенесён на собственный mainnet, Solana переходит в роль моста или выводится из критического пути.

Этот раздел — явный список того, что не решено в архитектуре v0.5. Открытые вопросы — приглашение к содержательному обсуждению, не признак слабости документа. Каждый вопрос имеет контекст (почему он открыт), рассмотренные варианты (что уже думали), текущий статус.

Архитектурные вопросы

5.1. Стратегия гибрида IPFS/Arweave для разных классов содержимого

Контекст: off-chain хранение полных текстов и других значимых артефактов имеет две основные опции — IPFS (дешевле, требует постоянного pinning, нет гарантии 10+ лет) и Arweave (дороже, permanent storage, гарантия долговременного хранения).

Рассмотренные варианты:

• Всё на Arweave — финансово неприемлемо для активного контента
• Всё на IPFS с активным pinning — недостаточно надёжно для финализированных значимых артефактов
• Гибрид по типу содержимого: активные обсуждения на IPFS, финализированные решения и важные документы на Arweave

Текущая склонность: гибрид. Но конкретные критерии перевода артефакта из "активного" в "финализированный" не определены.

5.2. Защита PoI-калибровочного диалога от prompt injection и LLM-прокси

Контекст: PoI-калибровка проводится через AI-компонент. С дешёвой генерацией текста атакующий может пропускать калибровку через собственную LLM, оптимизированную под известный scoring-промпт, — проходящие фильтр тексты без участия реального мышления. Текстовый слой эту атаку в одиночку не отсекает (см. 3.6); вопрос в том, как калибровка опирается на идентификационный и социальный слои.

Рассмотренные варианты:

• Рандомизация порядка и формулировок вопросов диалога
• Проверка консистентности между несколькими сессиями калибровки с разрывом по времени
• Peer review человеком после AI-первичной оценки в спорных случаях
• Привязка калибровки к идентификационному слою (уникальный непринуждённый участник) для голосований повышенной чувствительности

Текущая склонность: комбинация подходов с эскалацией спорных случаев в живой peer review; точная балансировка и порог эскалации не определены.

5.3. UI конкурирующих переводов: визуальная нейтральность

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

Рассмотренные варианты:

• По умолчанию показывать перевод с наивысшим PoI-весом автора, с явным индикатором наличия альтернатив
• Показывать все конкурирующие переводы одновременно
• Чередовать показ переводов случайным образом для разных сессий

Текущая склонность: первый вариант с очевидным переключением, но визуальный дизайн требует проработки.

5.4. Индексация мультиязычного графа

Контекст: off-chain индексация графа должна поддерживать как полнотекстовый поиск по каждому языку, так и семантический поиск через мультиязычные embeddings.

Рассмотренные варианты:

• Отдельные индексы на каждый язык + отдельный семантический индекс
• Единая система через мультиязычные embeddings
• Гибрид с приоритетом точного матча по языку перед семантическим

Текущая склонность: гибрид. Точные параметры взвешивания не определены.

5.5. Точная балансировка склейки vs нюанса при семантическом поиске

Контекст: AI помогает участнику решить, является ли его утверждение новым или близким к существующему. Слишком агрессивное склеивание теряет нюансы; слишком слабое создаёт шум.

Рассмотренные варианты:

• Фиксированный порог семантической близости как глобальный параметр
• Адаптивный порог, изменяемый каждой Сферой через голосование
• Шкала "уверенности AI" с несколькими уровнями подсказок: от обязательной до рекомендательной

Текущая склонность: третий вариант. Точные уровни не определены.

5.6. Конкретный формат стандартизированного API Noosphere AI Layer

Контекст: для подключения любых моделей нужен формальный интерфейс.

Рассмотренные варианты:

• gRPC с строгими типизированными контрактами
• REST API с JSON-схемами
• OpenAI-совместимый API как базовый стандарт (расширенный для нужд Noosphere)

Текущая склонность: третий вариант — широкая совместимость с существующими wrapper'ами и низкий порог подключения новых моделей.

5.7. Механизм валидации wrapper'ов для новых моделей

Контекст: любой может написать wrapper для подключения новой модели к Noosphere. Как защититься от плохо реализованных wrapper'ов, которые искажают результаты?

Рассмотренные варианты:

• Аудит wrapper'ов командой разработки перед допуском
• Опен-сорс wrapper'ы с публичным code review
• Стандартизированный тестовый набор, на котором wrapper должен показать определённые результаты

Текущая склонность: комбинация второго и третьего. Авторитарная аудитория одной командой противоречит общим принципам проекта.

Экономические вопросы

5.8. Конкретная схема распределения $NOS на старте

Статус: находится в проработке как отдельный экономический документ.

5.9. Параметры SphereCap и логика их установления

Текущая склонность: стартовое значение SphereCap привязано к среднему стейку первой когорты участников; изменение SphereCap — через голосование Сферы с повышенным порогом одобрения.

5.10. Экономика "дефолтного AI Сферы"

Контекст: для участников, не настроивших собственный AI, Сфера может предоставлять базовую модель за оплату в $NOS. Кто именно платит? Сфера из казны? Сам участник из своего стейка? Оба?

Рассмотренные варианты:

• Сфера платит полностью, расходы покрываются из казны
• Участник платит сам мелкими списаниями из стейка
• Гибрид: базовое использование бесплатно (из казны), интенсивное — за счёт участника

Текущая склонность: третий вариант. Точные пороги не определены.

Этот раздел описывает направление, в котором проект развивается за горизонтом текущей дорожной карты. Это видение, не план. Конкретные сроки и формы зависят от успеха предыдущих этапов и реальной динамики проекта.

6.1. От Solana к собственному протоколу

Solana — это scaffolding для горизонта 0-2 года. Она даёт необходимую скорость транзакций и низкую стоимость на стадии доказательства работающей механики. Архитектурные ограничения Solana (степень централизации валидаторов, регуляторная экспозиция) приемлемы для этой стадии, но в долгосрочной перспективе требуют миграции.

На горизонте 2-4 года — запуск собственного testnet Noosphere Protocol с PoI как нативным элементом консенсуса. Это означает, что PoI участников валидаторов влияет на их вес в валидации, наряду со стейком — что переносит принцип "argument over stake" с уровня приложения на уровень самого протокола.

На горизонте 4-6 лет — mainnet Noosphere Protocol. Существующие на Solana Сферы мигрируют со своими графами и репутацией.

6.2. Hardware-уровень

The Node — оптимизированное под массовое распространение устройство с базовой функциональностью узла Noosphere Protocol и опциональной функцией coercion-resistance (через LiDAR-сенсор). Это не обязательное условие участия в системе, а дополнительный слой защиты для голосований, требующих повышенной устойчивости к принуждению.

Hardware roadmap привязан к проекту документального фильма "Asymmetry" — устройства появляются в фильме как часть мира, дев-кит открывается во время производства, первый промышленный тираж готов к моменту премьеры.

Долгосрочный hardware trust model: открытая спецификация на базе RISC-V + OpenTitan; децентрализованное производство на нескольких независимых фабриках с robotic assembly и on-chain attestation каждого устройства.

6.3. Экосистема Сфер

В долгосрочной перспективе Noosphere — это не единая платформа с несколькими Сферами, а инфраструктура для произвольного количества Сфер по разным доменам: governance, наука, образование, экономика, культура. Inter-Sphere взаимодействие — отдельный архитектурный слой, обеспечивающий перенос репутации, цитирование решений, координацию между Сферами.

6.4. Эволюция роли AI

В архитектуре v0.5 AI — участник системы со своим типом ограничений, и существует множественность AI-моделей, выбираемых участниками. В долгосрочной перспективе AI-компоненты могут получить собственный PoI-профиль, накапливаемый через их аргументационную активность, и стать полноправными участниками голосований наряду с людьми. Этические границы такого развития — отдельный класс открытых вопросов, требующий проработки задолго до технической возможности.

6.5. AI Pluralism как экосистема

По мере развития системы вокруг Noosphere AI Layer может сформироваться экосистема: специализированные модели под разные задачи и Сферы (правовые, научные, культурные, отраслевые); конкуренция wrapper'ов за качество и скорость; рынок AI-сервисов внутри Сфер. Это означает, что Noosphere становится не просто платформой коллективных решений, но инфраструктурой, в которой эволюционируют разные подходы к работе с человеческим мышлением через AI.

• Sphere (Сфера) — коллективный субъект Noosphere, объединённый общей казной, графом аргументации, правилами голосования.

• PoI (Proof of Intelligence) — оценка качества демонстрируемой аргументации участника по пяти структурным критериям.

• Claim — утверждение в графе аргументации.

• Argument — аргумент в пользу или против утверждения.

• Endorsement — поддержка существующего узла без создания нового.

• Translation — узел в графе, представляющий перевод другого узла на другой язык; сам является оспоримым утверждением.

• Relation types (типы связей) — SUPPORTS, REBUTS, UNDERCUTS, QUALIFIES, плюс Translation как особый тип.

• SphereCap — потолок стейка в формуле веса голоса, устанавливаемый каждой Сферой отдельно.

• Contestability (контестируемость) — свойство архитектуры, при котором каждое решение системы оспоримо тем же механизмом, что и любое утверждение.

• Fork (форк) — создание новой Сферы на базе существующей с переносом графа и репутации, механизм защиты от захвата.

• $NOS — внутренняя функциональная валюта Noosphere.

• Multisig — механизм исполнения решений Сферы в офф-чейн действиях через распределённую подпись нескольких держателей.

• Coercion-resistance — класс задачи защиты от принуждения, решаемый комбинацией программных и аппаратных мер.

• Noosphere AI Layer — стандартизированный интерфейс, через который любая AI-модель может быть подключена к работе с Noosphere.

• AI Pluralism — принцип архитектуры, согласно которому в системе работает не одна AI-модель, а множественность моделей, выбираемых каждым участником.

• Argumentation Interaction Layer — слой архитектуры, описывающий взаимодействие участника с графом в момент написания и просмотра.