Использование электронного адреса в качестве основного способа связи с юридическим лицом

Правительство Российской Федерации распоряжением от 29 ноября 2025 года №3523-р утвердило «Национальную модель целевых условий ведения бизнеса до 2030 года», а также ключевые показатели эффективности реализации национальной модели и планы мероприятий («дорожную карту»)» по их достижению по следующим направлениям:

• Регистрация юридических лиц;
  
  
• Разрешение споров;
  
  
• Налоги;
  
  
• Трудовые отношения;
  
  
• Недвижимость;
  
  
• Интеллектуальная собственность;
  
  
• Закупки;
  
  
• Банкротство;
  
  
• Энергетика и коммунальная инфраструктура.

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

В ключевые показатели эффективности реализации национальной модели целевых условий ведения бизнеса до 2030 года по направлению «Регистрация бизнеса и налогообложение» включена «Доля юридических лиц, имеющих возможность использования адреса электронной почты для официальной коммуникации, в том числе с государственными органами», которая к 2028 году должна составить 70%. Этот показатель установлен для Минфина России, Минтруда России, Минцифры России, ФНС России, Фонда пенсионного и социального страхования Российской Федерации.

План мероприятий («дорожная карта») по достижению ключевых показателей эффективности реализации национальной модели целевых условий ведения бизнеса до 2030 года по направлению «Регистрация бизнеса и налогообложение» предполагает «введение на добровольной основе возможности использования электронного адреса (для обществ с ограниченной ответственностью, отнесенных к субъектам малого и среднего предпринимательства, осуществляющих нелицензируемые виды деятельности и не оказывающих услуги на финансовом рынке) в целях осуществления связи с юридическим лицом при сохранении у него физического адреса (в случае регистрации юридического лица по адресу места жительства лица, осуществляющего полномочия постоянно действующего исполнительного органа)».

Для реализации этой задачи предусмотрено:

• Разработка подхода к возможности использования на добровольной основе (в случае регистрации юридического лица по адресу места жительства лица, осуществляющего полномочия постоянно действующего исполнительного органа) адреса электронной почты во ФГИС  «Единый портал государственных и муниципальных услуг (функций)» в качестве основного способа связи с юридическим лицом при сохранении у него физического адреса (места нахождения постоянно действующего исполнительного органа).
  
  Для этого к январю 2027 года 
  
  
• ­Должен быть разработан и утвержден регламент по использованию электронного адреса в качестве основного способа связи с юридическим лицом;
  
  
• ­70 процентов юридических лиц должны иметь возможность использовать адрес электронной почты для официальной коммуникации, в том числе с государственными органами.
  
  
• Разработка понятия электронного адреса и требований к нему (п.1.2).
  
  К январю 2027 года планируется законодательно закрепить понятие электронного адреса;
  
  
• Разработка (доработка) информационно-технической инфраструктуры для использования электронного адреса в качестве основного способа связи с юридическим лицом (п.1.3).
  
  К январю 2028 года должен быть представлен доклад в Правительство РФ о наличие требуемой информационно-технической инфраструктуры для использования электронного адреса в качестве основного способа связи с юридическим лицом;
  
  
• Разработка порядка внесения электронного адреса в единый государственный реестр юридических лиц и одновременного ограничения сведений об адресе места нахождения постоянно действующего исполнительного органа (в случае регистрации юридического лица по адресу места жительства лица, осуществляющего полномочия постоянно действующего исполнительного органа) (п.1.4)
  
  К январю 2028 года планируется законодательное закрепление порядка внесения электронного адреса в единый государственный реестр юридических лиц и одновременного ограничения сведений об адресе места нахождения постоянно действующего исполнительного органа (в случае регистрации юридического лица по адресу места жительства лица, осуществляющего полномочия постоянно действующего исполнительного органа).

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

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

Процесс реализации затянут во времени, но это может быть связано с запланированным внесением изменений в законодательство, а это процесс небыстрый.

Разделение «физического адреса» (который остается) и «адреса для связи» (e-mail) может создать юридическую неопределенность. 

Цель «70% юридических лиц имеют возможность …» делает упор на наличие возможности, а не на реальное использовании. Ключевым, с моей точки зрения, должно быть не наличие возможности, а процент компаний, которые ею реально воспользовались и для которых электронная почта стала основным или существенным каналом связи с государственными органами.

К сожалению, ничего не сказано о том, какая именно система электронной почты может использоваться – любая, только российская, или же, скажем, специальная защищённая электронная почта, которая сможет обеспечить надёжную идентификацию участников переписки, гарантировать доставку конкретному получателю и уведомление об этом отправителя? 

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=520354

Становой хребет подотчётности: Обеспечение долговременной сохранности алгоритмов в автоматизированном обществе. Часть 4: Рынки, память и машинная логика (3)

(Окончание, предыдущую часть см. https://rusrim.blogspot.com/2026/02/4-2.html ) 

Реконструкция инцидента как метод расследования

Когда на финансовых рынках что-то идёт не так, следователи начинают со сбора свидетельств и доказательств. Они собирают:

• Журналы аудита оперативной деятельности,
  
  
• Отметки времени, с точностью до миллисекунды,
  
  
• Книги заявок / распоряжений,
  
  
• Переписку,
  
  
• Конфигурационные файлы,
  
  
• Проектную документацию,
  
  
• Решения в рамках управления изменениями.

Далее они восстанавливают последовательность событий -  перемещаются назад во времени и воссоздают состояние системы до, во время и после аномалии.

Данный процесс выглядит практически идентичным реконструкции исторических событий по архивным документам – и это не метафора, а подход.

Системы для ведения торгов не рассказывают свои истории. Об истории их функционирования говорят свидетельства / доказательства. Вот почему так важны журналы аудита, это не техническая телеметрия. Ну а надзор - необходимое условие выживания.

Почему финансовые рынки раньше осознали проблему

Рынки почувствовали хрупкость автоматизации задолго до того, как это сделало сообщество специалистов по ИИ. Самым известным примером является «Мгновенный крах» (Flash Crash) 2010 года (резкое падение американского рынка акций 6 мая 2010 года, спровоцированное проведением мнимых сделок со срочными биржевыми контрактами путем выставления и молниеносного снятия 19 тысяч заявок на покупку и продажу ценных бумаг объемом до $200 млн с помощью программ высокочастотной торговли. Злоумышленник был изобличён лишь через 5 лет – Н.Х.), но было и бесчисленное множество других, менее значительных инцидентов, в которых автоматизированные стратегии неожиданно делали ситуацию неконтролируемой контроля, или же взаимодействие между системами приводило к непредвиденным последствиям.

Говоря о ранних сбоях на автоматизированных рынках, люди часто высказываются абстрактно. Однако 6 мая 2010 года наступил момент, привлёкший к данной проблеме внимание всего мира – это был так называемый «мгновенный крах». В течение нескольких минут фондовые рынки США пережили ошеломляюще резкое падение, потеряв почти 1 триллион долларов рыночной стоимости, после чего практически мгновенно восстановились. Одни однотипные сделки заключались на сумму в один цент, другие - на 100 тысяч долларов. Рыночные данные рассинхронизировались. Книги заявок опустошались, а затем снова наполнялись с поразительной скоростью.

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

«Мгновенный крах» кое-что прояснил задолго до того, как ИИ вошел в число основных тем дискуссий по вопросам политик. Сложные автоматизированные системы способны дестабилизировать целые сектора экономики за считанные секунды, и единственный способ понять, что произошло, - это проследить цепочку свидетельств о действиях системы. Финансовые рынки на собственном горьком опыте убедились, что подотчетность невозможна без документов, достаточно подробных для воссоздания момента краха.

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

Регуляторы пришли к простому и глубокому выводу:

• Системы быстрее людей,
  
  
• Люди могут быть не в состоянии вмешаться в режиме реального времени,
  
  
• Мероприятия контроля и надзора после события невозможен в отсутствии памяти,
  
  
• Документальный «след» является единственным способом, обеспечивающим возможность понять действия автоматизированных систем.

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

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

Возвращаясь к современному стратегическому управлению искусственным интеллектом

Если сопоставить финансовое регулирование с Законом Евросоюза об ИИ, то параллели очевидны:

• На финансовых рынках требуется документация о жизненном цикле. Закон об ИИ требует документации о жизненном цикле.
  
  
• На финансовых рынках требуются журналы аудита. Закон об ИИ требует протоколирования в журналах аудита, достаточно для реконструкции решений.
  
  
• На финансовых рынках требуются история версий и журналы изменений. Закон об ИИ требует управления версиями и свидетельств изменений.
  
  
• На финансовых рынках требуется сохранение данных, достаточных для обеспечения исполнения законодательно-нормативных требований. Закон об ИИ требует сохранение данных, достаточных для обеспечения надзора и контроля.
  
  
• На финансовых рынках требуется обеспечить возможность воссоздания автоматизированного поведения. Закон об ИИ требует обеспечить возможность реконструкции действий системы.

Эти два режима [нормативно-правового регулирования – Н.Х.] эволюционировали независимо друг от друга, но их объединяет одна и та же ключевая идея: стратегическое управление опирается на свидетельства / доказательства.

Финансовые рынки пришли к этому первыми, потому что имевшие там место сбои были мгновенными и измеримыми. ИИ только сейчас достигает подобного уровня интеграции в общество, и регулирующие органы начинают понимать ту же истину: подотчетность невозможна без памяти.

Сдвиг в серии постов: От осознания проблемы к архитектуре

В 4-й части серия постов переходит от осознания проблемы к пониманию её архитектуры её решений. Финансовый сектор показывает, как может выглядеть обеспечение сохранности алгоритмов при реализации в оперативной деятельности. В ней представлена самая ясная и понятная из существующих моделей сохранения доказательной базы (evidential recordkeeping) для автоматизированных систем.

Отсюда становятся понятными дальнейшие шаги:

• В 5-й части будут описаны компоненты «пакета» для обеспечения сохранности алгоритмов (algorithm preservation package);
  
  
• В 6-й части будут рассмотрены экспертиза ценности, виды ценности, установление и отслеживание сроков хранения;
  
  
• В 7-й части речь пойдёт о том, что означает проектирование систем с функцией сохранения памяти по умолчанию.

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

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

Эндрю Поттер (Andrew Potter)

Источник: сайт Substack
https://metaarchivist.substack.com/p/bones-of-accountability-preserving-874 

Порядок информирования ФСБ России о компьютерных атаках и компьютерных инцидентах

ФСБ России приказом от 25 декабря 2025 года №547 утвердила «Порядок информирования ФСБ России о компьютерных атаках и компьютерных инцидентах, реагирования на них, принятия мер по ликвидации последствий компьютерных атак, проведенных в отношении значимых объектов критической информационной инфраструктуры Российской Федерации и иных информационных ресурсов Российской Федерации, принадлежащих органам и организациям, на которые возложены обязанности, предусмотренные частью 4 статьи 9 Федерального закона от 26 июля 2017 г. №187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»».

Приказ вступил в силу с 30 января 2026 г.

Субъекты критической информационной инфраструктуры (КИИ) РФ обязаны (п.1):

• Информировать ФСБ России обо всех компьютерных атаках и компьютерных инцидентах;
  
  
• Реагировать на них, и 
  
  
• Принимать меры по ликвидации последствий компьютерных атак, проведенных в отношении значимых объектов КИИ, принадлежащих им на праве собственности, аренды или ином законном основании. 

В части информационных ресурсов Российской Федерации, принадлежащих органам и юридическим лицам на праве собственности, аренды или ином законном основании, то их руководители обязаны информировать ФСБ России обо всех компьютерных атаках и компьютерных инцидентах, связанных с функционированием принадлежащих им информационных ресурсов (п.2). Это должны делать руководители:

• Государственных органов (за исключением органов внешней разведки РФ, органов государственной охраны, федерального органа обеспечения мобилизационной подготовки органов государственной власти РФ, федерального органа исполнительной власти, уполномоченного в области обеспечения безопасности критической информационной инфраструктуры РФ);
  
  
• Государственных унитарных предприятий;
  
  
• Государственных учреждений;
  
  
• Государственных фондов;
  
  
• Государственных корпораций (компаний);
  
  
• Иных российских юридических лиц, которые, если иное не предусмотрено международным договором РФ, находятся под контролем Российской Федерации, и (или) субъекта РФ, и (или) контролируемых ими совместно или по отдельности лиц.

Информирование ФСБ России осуществляется путем направления информации в Национальный координационный центр по компьютерным инцидентам (НКЦКИ) в соответствии с определенными форматами представления информации о компьютерных атаках и компьютерных инцидентах в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации с использованием технической инфраструктуры НКЦКИ, предназначенной для отправки, получения, обработки и хранения уведомлений и запросов в рамках информационного взаимодействия с субъектами КИИ, а также с иными не являющимися субъектами КИИ органами и организациями, в том числе иностранными и международными. 

В случае отсутствия подключения к данной технической инфраструктуре информирование осуществляется посредством почтовой связи или электронной связи по адресам НКЦКИ, указанным на официальном сайте в сети «Интернет» ( www.cert.gov.ru ) (п.2).

Информация о компьютерном инциденте направляется в НКЦКИ (п.3):

• в значимом объекте КИИ - в срок не позднее 3 часов с момента его обнаружения; 
  
  
• в иных объектах КИИ - в срок не позднее 24 часов с момента его обнаружения;
  
  
• на информационном ресурсе Российской Федерации органа (организации) - в срок не позднее 24 часов с момента его обнаружения.

Информация о компьютерной атаке направляется в НКЦКИ:

• проведенной в отношении объекта КИИ или информационного ресурса Российской Федерации органа (организации), в срок не позднее 24 часов с момента обнаружения компьютерной атаки.

Субъекты КИИ, которые осуществляет деятельность в банковской сфере и в иных сферах финансового рынка, информация также направляют в Банк России. 

Для подготовки к реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак субъектом КИИ разрабатывается план реагирования (п.5), который утверждается руководителем (п.6). Копия плана направляется в НКЦКИ.

Проект плана реагирования, содержащий эти положения и проект о внесении изменений в него разрабатываются субъектом КИИ при методическом обеспечении НКЦКИ и до их утверждения направляются на согласование в Центр защиты информации и специальной связи ФСБ России (п.8).

Субъект КИИ не реже одного раза в год обязан организовывать и проводить тренировки по отработке мероприятий плана реагирования. Объем и содержание тренировки определяются субъектом КИИ исходя из мероприятий, содержащихся в плане реагирования (п.10).

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

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

В ходе ликвидации последствий компьютерных атак субъектом КИИ принимаются меры по восстановлению функционирования и проверке работоспособности значимого объекта КИИ (п.13)

Субъект КИИ обязан информировать НКЦКИ в срок не позднее 48 часов после завершения мероприятий по реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак о результатах таких мероприятий (п.14).

Информацию о результатах реагирования на компьютерные инциденты и принятия мер по ликвидации последствий компьютерных атак, связанных с функционированием принадлежащих органам (организациям) информационных ресурсов Российской Федерации, органы (организации) в течение 24 часов с момента окончания мероприятий направляют в НКЦКИ.

Органы (организации) в целях принятия мер по ликвидации последствий компьютерных атак, связанных с функционированием принадлежащих им информационных ресурсов РФ, обязаны (п.16):

• Определить состав подразделений и должностных лиц, ответственных за проведение мероприятий, 
  
  
• Их задачи в рамках принимаемых мер, 
  
  
• Очередность информационных ресурсов РФ (их структурных элементов), в отношении которых будут приниматься меры по ликвидации последствий компьютерных атак, 
  
  
• Перечень мер по восстановлению функционирования информационного ресурса РФ и 
  
  
• Направить указанную информацию в НКЦКИ 

Органы (организации) после ликвидации последствий компьютерных атак и принятия мер по восстановлению функционирования и проверке работоспособности информационных ресурсов РФ обязаны информировать об этом НКЦКИ в течение 24 часов с момента завершения таких мер (п.17).

Мой комментарий: Документ содержит требования к созданию целого ряда документов. Это:

План реагирования на компьютерные инциденты (ПР) – это основной документ, который должен быть разработан (п.5-9 Порядка). В этом документе может быть определен:

• Состав группы реагирования на инциденты с перечислением их ролей и контактов (включая круглосуточные), а также порядок их взаимодействия;
  
  
• Процесс реагирования при обнаружении;
  
  
• Процедура информирования: кто, в каком формате (ссылка на форму), через какой канал, кому (внутри, в НКЦКИ, в Банк России) отправляет уведомление;
  
  
• Восстановление: Приоритеты объектов (как в п.12), процедуры;
  
  
• Завершение: Критерии закрытия инцидента, процедура итогового информирования НКЦКИ (п.14).

Поскольку данный документ требуется согласовывать с ФСБ/Банком России, нужно обязательно сохранять все версии и протоколы согласований.

Документы по проведению тренировок – прежде всего включают утвержденную программу и график тренировок, а также отчет об итогах тренировки, ключевой документ, подтверждающий выполнение п.10 и обосновывающий изменения в Плане реагирования. Все отчеты по тренировкам хранятся для предъявления ФСБ.

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

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=523709

Становой хребет подотчётности: Обеспечение долговременной сохранности алгоритмов в автоматизированном обществе. Часть 4: Рынки, память и машинная логика (2)

(Продолжение, предыдущую часть см. https://rusrim.blogspot.com/2026/02/4-1.html )

Журналы аудита как архитектура для создания и сохранения доказательств

Если в других секторах экономики термин «журнал аудита» (audit trail) используется довольно вольно, то в финансовой сфере он имеет точное значение. Именно архитектура для создания и сохранения доказательств (evidential architecture) обеспечивает регуляторам возможность точно реконструировать действия системы.

На практике это означает:

• Каждое связанное с торговым распоряжением событие должно документироваться / протоколироваться,
  
  
• Каждое изменение должно отслеживаться,
  
  
• Каждое исполнение должно быть связано с его первоисточником,
  
  
• Каждое действие системы должно быть запротоколировано,
  
  
• Каждое изменение в логике алгоритмов должно быть задокументировано,
  
  
• Все отметки времени должна быть синхронизированы [с эталонным временем – Н.Х.] в рамках экосистемы.

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

Именно поэтому возможность реконструкция истории торгов стала самостоятельным формальным понятием. В 2016 году в Соединенных Штатах Комиссией по торговле товарными фьючерсами (Commodity Futures Trading Commission, CFTC) был предложен проект нормативного акта «Регулирование автоматизированной торговли» (Regulation Automated Trading, Reg AT, см. https://www.federalregister.gov/documents/2016/11/25/2016-27250/regulation-automated-trading ), который прямо потребовал от занимающихся алгоритмической торговлей компаний вести документацию о разработке и тестировании, журналы изменений и дела по контролю и управлению рисками. Несмотря на то, что правила Reg AT так и не вступили в силу в полной мере (В 2020 году CFTC отозвала проект Reg AT и заменила его новым предложением под названием «Принципы оценки рисков электронной торговли» (Electronic Trading Risk Principles) – Н.Х.), его основные идеи закрепились в практике деятельности рынков и перешли в более поздние рекомендации регулирующих органов. Логика документирования сохранилась, пусть даже сами правила Reg AT так и не были утверждены.

Именно посредством журналов аудита обеспечение сохранности алгоритмов постепенно становится нормой.

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

Досье разработчика и след оперативной деятельности

Одна из наиболее очевидных параллелей между финансовым регулированием и Законом Евросоюза об искусственном интеллекте (ИИ) заключается в том, как они проводят грань между проектной документацией и свидетельствами оперативной деятельности (эксплуатации). В финансовом секторе этот слой проектно-конструкторской документации не всегда представлен в виде формального, унифицированного «досье разработчика» (developer file). Тем не менее, регуляторы уже давно ожидают от занимающихся автоматизированной или алгоритмической торговлей компаний ведения документации о разработке и тестировании. В различных юрисдикциях сюда входят:

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

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

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

Совместно эти два слоя дают возможность регулирующим органам реконструировать как намерения разработчиков алгоритма, так и результаты его работы. Закон Евросоюза об ИИ отражает это разделение посредством разделения субъектов на поставщиков (providers) и внедряющие стороны (deployers). В финансовом регулировании это выражается через понятия «разработчики систем» (system developers) и «инфраструктура для реальной торговли» (live trading infrastructure).

Архитектура та же, лишь названия разные.

(Окончание следует, см. https://rusrim.blogspot.com/2026/02/4-3.html )

Эндрю Поттер (Andrew Potter)

Источник: сайт Substack
https://metaarchivist.substack.com/p/bones-of-accountability-preserving-874