Техническое задание: Dominium¶

ERP-платформа для управления коммерческой недвижимостью

Этап 0: Философия и рамка системы

Версия 2.2 (2026-04-29)

Содержание¶

Миссия и видение продукта
Анализ существующих систем
Целевые пользователи и стейкхолдеры
Два режима платформы
Market Intelligence Layer (рыночная аналитика)
Принятые ключевые решения
Модель данных: юридическая и операционная топология
Функциональная архитектура (модули)
Модель «живого договора»
Billing Engine: типы расчётов
Налоговый модуль
Индексация и условные формулы
Система метрик и KPI
Сценарное моделирование и конструктор
Ролевые интерфейсы
Интеграционная карта
Технологические принципы и стек
Дорожная карта, команда и бюджет
Явные не-цели MVP
Следующий шаг: Этап 1

1. Миссия и видение продукта¶

Миссия¶

Создать универсальную облачную платформу управления коммерческой недвижимостью, которая объединяет четыре перспективы — управляющего, собственника, акционера и финансового партнёра (банк/инвестор) — в единой системе с общей моделью данных, сценарным моделированием и decision-first архитектурой.

Платформа проектируется как независимый продукт, не привязанный к конкретному оператору или объекту. Любой собственник коммерческой недвижимости — от владельца одного помещения стрит-ретейл до управляющей компании с портфелем из десятков объектов — должен найти в системе инструмент, соответствующий его масштабу и задачам.

Dominium — это многоуровневая платформа. Первый уровень — операционная система управления активом: учёт, биллинг, договоры, кабинеты собственников и арендаторов, эксплуатация. Второй уровень — рыночная аналитика, построенная на обезличенных данных всех собственников в системе: средние ставки, вакансия, платёжная дисциплина по сегментам и локациям. На горизонте второй фазы — третий уровень, предиктивная аналитика: прогнозирование доходности, оптимизация ставок, раннее обнаружение рисков. В дальней перспективе — четвёртый уровень, прескриптивная аналитика: рекомендации действий собственникам и банкам на основе накопленных моделей. Архитектура открыта для добавления новых уровней по мере роста продукта. Между уровнями — сетевой эффект: чем больше собственников ведут операционный учёт в Dominium, тем точнее аналитика, тем ценнее она для банков-партнёров и для самих собственников. Это даёт устойчивое стратегическое преимущество, основанное не на технологии, а на накопленных данных.

Поверх многоуровневой платформы Dominium проектируется AI-Native архитектурный слой: AI/ML — не приклеенная фича, а отдельный слой, спроектированный одновременно с моделью данных. AI работает на двух горизонтах: AI-Native MVP (Document AI для импорта существующих договоров, AI-копилот в Telegram-боте управляющего, LLM-обёртка над конструктором сценариев) — снимает барьеры внедрения и формирует «магические моменты» для пользователей с первого дня; AI-Enhanced (расширение Этажа 3 — predictive Tenant Health Score, vacancy forecasting, anomaly detection, smart alerts ranking, авто-комментарии для банка-кредитора) — уточняет уже накопленную аналитику при достижении критической массы данных. См. ADR-009 и ADR-010.

Видение¶

Система, в которой:

Управляющий принимает решения на основе данных, а не интуиции и Excel
Собственник в реальном времени видит состояние актива и моделирует сценарии
Собственник видит обезличенный бенчмарк рынка по своему сегменту — средние ставки, вакансию, платёжную дисциплину похожих объектов
Акционер получает прозрачную сводку без участия команды
Банк/инвестор получает аналитику залогового актива без ручных запросов
Банки получают рыночную аналитику для скоринга бизнес-планов заёмщиков — на основе реальных операционных данных, а не оценочных моделей
Арендатор через личный кабинет видит счета, задолженность и подаёт заявки
Управляющие сдают ежедневные отчёты через Telegram одним кликом
Каждый договор — живой объект с историей, условиями и прогнозами
AI-помощники работают рядом с каждой ролью: управляющий описывает день голосом или одной фразой — копилот раскладывает по сущностям; собственник формулирует сценарий естественным языком — система пересчитывает; новый клиент загружает старые PDF-договоры — Document AI извлекает поля и заполняет «живой договор»
Все суммы хранятся без налогов (NET); налоговый слой — подключаемый модуль
Данные собственников используются в обезличенной форме, с гарантиями приватности и правом отказа от участия в аналитике

Ключевое отличие от существующих решений¶

Существующие системы	Dominium
Спроектированы от учёта	Спроектирована от управленческого решения
Объект = набор площадей с договорами	Объект = инвестиционный актив с жизненным циклом
Один интерфейс для всех	Разные интерфейсы для разных ролей
Ретроспективная аналитика	Сценарное моделирование + конструктор сценариев
Договор = PDF в архиве	Договор = живой объект с timeline условий
Нет роли «Банк»	Банк — стейкхолдер с dashboard в обоих режимах
Нет роли «Акционер»	Акционер — отдельный read-only интерфейс с PDF-отчётом
Налог зашит в ставку	Ставки NET + подключаемый налоговый модуль
Привязка к одной юрисдикции	Расширяемая налоговая архитектура (РФ, СНГ, другие)
Плоская модель данных	Двойная иерархия: юридическая + операционная
Кадастровая стоимость не используется	Автоподгрузка из Росреестра, расчёт LTV тремя методами
Ежедневные отчёты — телефон/Excel	Telegram-бот: 1 клик «Ничего не произошло» или 5 блоков
Аналитика только внутри своих данных	Рыночные бенчмарки на основе обезличенных данных всех собственников в системе
Каждая компания работает в своей информационной изоляции	Сетевой эффект: чем больше собственников, тем точнее аналитика для каждого
AI как опциональная фича сбоку	AI как архитектурный слой, спроектированный одновременно с моделью данных и Event Sourcing

Критерии успеха MVP¶

Управляющий ведёт полный арендный учёт без Excel и параллельных систем
Собственник видит real-time dashboard с KPI и моделирует сценарии
Акционер получает PDF-отчёт автоматически, видит сводку через ЛК
Банк получает read-only аналитику залогового актива с тремя методами LTV
Арендатор видит счета (NET + налог), задолженность, пени, подаёт заявки
Управляющие сдают ежедневные отчёты через Telegram (≥90% compliance)
Сценарное моделирование: предустановленные типы + конструктор
Корректный расчёт налогов по российским режимам с готовностью к другим юрисдикциям
Собственники и банки-партнёры используют аналитический слой в базовой конфигурации: обезличенные агрегаты ставок и вакансии по сегментам с соблюдением k-anonymity (минимум 5 наблюдений от 3 разных собственников)
Минимум один банк-партнёр работает с системой — в режиме mortgage_monitoring (мониторинг своего залогового актива с обезличенным бенчмарком по локации) или в режиме analytics_partnership (доступ к макро-аналитике для скоринга), либо в обоих режимах сразу
Document AI извлекает структурированные поля из существующих PDF-договоров аренды с точностью, достаточной для автозаполнения «живого договора» с проверкой человеком (target: ≥85% полей корректно при первой попытке)
AI-копилот в Telegram-боте управляющего распознаёт свободный текст и голосовые сообщения и предлагает структурированную запись (Manager Report, Showing, Incident, Tenant Intention) с подтверждением управляющим

2. Анализ существующих систем¶

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

Российские системы¶

Система	Сильные стороны	Критические ограничения
ИТИС:Маркет	Широкий функционал. Известна на рынке. Арендный учёт, счётчики.	Устаревший UX. Плоская модель данных. Нет роли «Банк» и «Акционер». Нет сценарного моделирования. Нет Tenant Health Score. Нет поддержки мультивладения. Нет Telegram-интеграции.
ArendaSoft	Простота. Быстрое внедрение. Базовый арендный учёт.	Ограниченный функционал. Нет мультиобъекта. Нет условной индексации. Нет API. Не масштабируется.
1С:Аренда и управление недвижимостью (модуль для 1С:ERP)	Интеграция с 1С. Бухгалтерский учёт. Учёт договоров аренды и счетов. Управление эксплуатацией.	Привязан к экосистеме 1С (нужен 1С:ERP). Управленческая аналитика слабая. Нет банковского dashboard и сценарного моделирования. Нет роли «Акционер». Не предполагает работу с залоговыми активами.
CAFM ODIN	Полнофункциональная CAFM-система для эксплуатации крупных коммерческих объектов (БЦ, ТРЦ). Развитые модули заявок, ТО/ППР, обходов, учёта счётчиков. Реальные крупные клиенты (ТРЦ Казань Mall, БЦ Депо). Под управлением — более 2 млн м².	Фокус на физической эксплуатации здания, не на инвестиционно-арендной модели актива. Нет роли «Банк/Инвестор» и сценарного моделирования. Нет мультивладения и работы с залоговыми активами. Нет рыночной аналитики и бенчмарков.
СберБизнес — Единое окно для управления арендным бизнесом	Встроено в банк-клиент Сбера. Управление счетами и платежами арендаторов. Налоговый календарь. Аналитика локаций через СберАналитику.	Привязано к одному банку. Нет роли управляющего и сценарного моделирования. Не покрывает задачи мультивладения и портфельного управления. Аналитика на основе данных Сбера, не первичных операционных.

Международные системы¶

Система	Сильные стороны	Критические ограничения
Yardi Voyager	Лидер мирового рынка. Полный функционал. BI, budgeting, accounting.	Стоимость (от $50K/год). Не адаптирован к РФ. Монолитная архитектура. Внедрение 6–12 мес.
MRI Software	Гибкий. API-first. Модульная архитектура.	Нет русской локализации. Не понимает российские налоговые режимы. Нет интеграции с 1С/ЭДО.
SAP RE-FX	Корпоративный уровень. Интеграция с SAP ERP.	Избыточная сложность. Требует SAP-экосистему. Стоимость от $200K. Не для среднего бизнеса.
Entrata / AppFolio	Современный UX. Облачные, SaaS. ЛК арендатора.	Фокус на жилую недвижимость. Не подходят для коммерческой. Нет российских интеграций.
Argus Enterprise	Лучший DCF-анализ. Сценарное моделирование.	Только аналитика, не ERP. Нет операционного управления. Нет billing, нет договоров. $15K+/год.

Сводная матрица возможностей¶

Функция	ИТИС	ArendaSoft	Yardi	MRI	Argus	Dominium
Двойная иерархия (ЕГРН + операционная)	✗	✗	~	~	✗	✓
Мультивладение в одном здании	~	✗	✓	✓	✗	✓
Живой договор (timeline условий)	✗	✗	~	~	✗	✓
6+ типов расчёта аренды	~	✗	✓	✓	✗	✓
Условная индексация (ИПЦ с порогом)	✗	✗	~	✓	~	✓
Tenant Health Score	✗	✗	✗	✗	✗	✓
Сценарное моделирование + конструктор	✗	✗	~	~	✓	✓
Dashboard банка / инвестора	✗	✗	✗	~	~	✓
Dashboard акционера	✗	✗	✗	✗	✗	✓
ЛК арендатора	✗	✗	✓	✓	✗	✓
Налоговый модуль (ОСНО/УСН/ОЭЗ)	~	~	✗	✗	✗	✓
Telegram-бот для управляющих	✗	✗	✗	✗	✗	✓
Воронка показов с источниками (Авито/ЦИАН)	✗	✗	~	~	✗	✓
Учёт инцидентов и намерений арендаторов	✗	✗	✗	✗	✗	✓
Кадастровая стоимость из Росреестра	✗	✗	✗	✗	✗	✓
Жизненный цикл юнита (split/merge)	✗	✗	~	~	✗	✓
Жизненный цикл владения	✗	✗	~	~	✗	✓
Расширяемые типы арендных объектов	✗	✗	~	✓	✗	✓
Blockchain-ready аудит	✗	✗	✗	✗	✗	✓
Облако + API-first	✗	✗	~	✓	~	✓

Обозначения: ✓ — полноценная поддержка, ~ — частичная, ✗ — отсутствует.

Вывод¶

На рынке отсутствует система, которая одновременно: понимает российскую специфику (ЕГРН, НДС/УСН, 1С, ЭДО, кадастровая стоимость), предоставляет decision-first аналитику, поддерживает четыре перспективы (управляющий / собственник / акционер / банк), обеспечивает гибкость модели данных, включает сценарное моделирование с конструктором, интегрируется с инструментами ежедневной работы (Telegram, Авито, ЦИАН). Dominium закрывает эту нишу.

3. Целевые пользователи и стейкхолдеры¶

Матрица ролей¶

Роль	Категория	Ключевые задачи	Тип доступа
Собственник	Стратегический	Dashboard портфеля, KPI, сценарии, P&L, CAPEX	Полный (свои объекты)
CEO УК	Стратегический	Сводная аналитика по всем объектам УК	Полный (все объекты УК)
Акционер	Стратегический	Сводная финансовая картина, тренды, PDF-отчёты	Read-only (выручка, задолженность, заполненность)
Asset Manager	Тактический	Доходность, позиционирование, tenant-mix	Назначенные объекты
Property Manager (управляющий)	Операционный	Договоры, платежи, заявки, дебиторка, ежедневный отчёт	Назначенные объекты
Leasing Manager (менеджер по аренде)	Операционный	Воронка показов, источники лидов, офферы, согласование	Leasing pipeline
Главный инженер	Операционный	Эксплуатация, ППР, заявки, счётчики	Эксплуатация
Бухгалтер	Учётный	Начисления, налоги, акты, сверки, 1С, банковские выписки	Финансовый контур
Юрист	Учётный	Договоры, условия, сроки, риски	Договорной контур
Арендатор	Внешний	Счета, оплата, задолженность, пени, заявки	Личный кабинет
Банк-партнёр	Внешний (контракт analytics_partnership)	Скоринг бизнес-планов заёмщиков, анализ сегментов, бенчмарки рынка	Read-only обезличенная макро-аналитика (все локации, все сегменты)
Банк-кредитор	Внешний (контракт mortgage_monitoring)	Мониторинг залогового актива, LTV, ранние алерты по ковенантам	Read-only данные заёмщика + микро-бенчмарк по зданию + макро-бенчмарк по локации
Оценщик	Внешний (временный доступ)	Сравнительный подход в отчётах об оценке, выписки бенчмарков	Read-only данные оцениваемого объекта + обезличенные бенчмарки сегмента/локации
Инвестор	Внешний (фаза 2)	Оценка предложения о входе в проект через долю	Read-only обезличенные финансовые показатели по предложению собственника

Особенности ключевых ролей¶

Акционер¶

Видит только финансовую сводку: выручка по портфелю, общая задолженность, заполненность, тренд за период. Не видит деталей договоров, имён арендаторов, оперативных вопросов. Получает автоматический PDF-отчёт первого числа каждого месяца. Может зайти в ЛК через web (десктоп/планшет).

Property Manager (управляющий)¶

Каждое утро в 09:00 получает Telegram-сообщение от системы. Должен сдать ежедневный отчёт в 5 блоках: показы, инциденты, намерения арендаторов, состояние объекта, новые договоры. Если ничего не произошло — нажимает кнопку «Ничего не произошло» (1 клик). Если не сдал к 10:00 — система алертит руководителя.

Leasing Manager (менеджер по аренде)¶

Работает с воронкой показов. Источники лидов: Авито, ЦИАН, сайт, звонок, сарафанное радио. Этапы: запрос → показ → КП → согласование → договор → заезд. Конверсия каждого этапа отслеживается, аналитика по источникам.

Особенности роли «Банк-партнёр»¶

Банк-партнёр — финансовая организация, заключившая с Dominium партнёрское соглашение на доступ к рыночной аналитике (тип контракта analytics_partnership). В отличие от банка-кредитора, банк-партнёр не обязательно является кредитором конкретных собственников в системе — он покупает доступ к обезличенной макро-аналитике для собственных задач: скоринг бизнес-планов потенциальных заёмщиков, оценка реалистичности заявленных доходностей, анализ сегментов рынка.

Что видит:

Обезличенные агрегаты по сегментам и локациям: средние ставки, медианы, перцентили, вакансия, платёжная дисциплина — по всему рынку, который ведёт операционный учёт в Dominium.
Срезы по типам объектов (офис, ритейл, склад), по площадным группам, по географическим зонам.
Динамика показателей во времени.
Бенчмарки локаций для сравнения с заявленными арендаторами цифрами.

Что не видит:

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

Гарантии обезличивания:

Все агрегаты строятся с соблюдением k-anonymity: минимум 5 наблюдений от 3 разных собственников. Если в сегменте недостаточно данных для обезличивания — агрегат не показывается. Дополнительное правило: доля одного собственника в любом сегменте не превышает 50%.

Бизнес-модель:

Банк-партнёр платит за доступ по модели подписки или per-query. Конкретные условия и тарифные планы — в разделе 18 (Дорожная карта, фаза 2). На стадии MVP — пилотный режим с минимум одним банком-партнёром.

Один банк может быть и партнёром, и кредитором одновременно — это разные контракты с разными правами доступа.

Особенности роли «Банк-кредитор»¶

Банк-кредитор — финансовая организация, выдавшая кредит конкретному собственнику под залог объекта недвижимости, который ведёт операционный учёт в Dominium. Доступ предоставляется на основании соглашения о мониторинге залогового актива (тип контракта mortgage_monitoring) — этот контракт подписывается между банком и собственником-заёмщиком, и действует только пока активен кредит.

Что видит:

Полные операционные данные только своего заёмщика и только по заложенному объекту: ставки, заполняемость, NOI, дебиторскую задолженность, динамику показателей, кадастровую стоимость и расчёт LTV тремя методами.
Микро-бенчмарк по зданию, в котором находится залог — обезличенный агрегат по соседним собственникам в том же здании (если их достаточно для соблюдения k-anonymity). Это позволяет понять, едет ли актив заёмщика по рынку или у него индивидуальные проблемы с менеджментом.
Макро-бенчмарк по локации — те же агрегаты, что и у банка-партнёра, но в контексте конкретного актива.
Историю изменений по объекту с цифровыми подписями: важно для ретроспективного анализа при спорах.

Что не видит:

Других собственников и заёмщиков (даже своих, в других объектах).
Индивидуальные данные соседей по зданию (только обезличенный агрегат).
Любые объекты вне залогового соглашения.

Особенности доступа:

Доступ автоматически прекращается при закрытии кредита — соглашение становится неактивным, права отзываются.
Все запросы к данным заёмщика логируются с цифровыми подписями: банк имеет правовое основание, собственник видит факт обращения.

Один банк может быть и кредитором, и партнёром одновременно — это разные контракты с разными правами доступа.

Особенности роли «Оценщик»¶

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

Что видит:

Полные операционные данные только оцениваемого объекта: исторические ставки, динамика заполняемости, операционные расходы, кадастровая стоимость.
Обезличенные бенчмарки рынка по сегменту и локации оцениваемого объекта — для применения сравнительного подхода к оценке.
Документы по объекту: договоры аренды (без персональных данных арендаторов), правоустанавливающие документы, технические паспорта.

Что не видит:

Другие объекты в системе.
Финансовые показатели соседей по зданию (только обезличенный микро-бенчмарк).
Информацию о собственнике вне контекста оцениваемого объекта.

Особенности доступа:

Срок доступа фиксирован контрактом — обычно 14-30 дней с возможностью продления.
Все действия логируются: банк или собственник видят, что именно оценщик смотрел и какие данные использовал в отчёте.
Оценщик может выгрузить выписку обезличенных бенчмарков для включения в свой отчёт — с подписью и датой формирования.

Бизнес-модель:

Оценщик не платит за доступ к данным напрямую — оплата за доступ встроена в его гонорар по контракту с заказчиком оценки (банк или собственник). Конкретные тарифы — в разделе 18 (Дорожная карта).

4. Два режима платформы¶

Платформа поддерживает два режима. Оба имеют доступ к банковскому каналу — подключение dashboard для банка/инвестора доступно в любом режиме.

Режим «Simple»¶

Для собственника одного или нескольких небольших объектов. Типичные сценарии входа:

Собственник выбирает решение для управления своим активом (без банка)
Получение кредита на покупку ГАБ (банк рекомендует платформу)
Приобретение нескольких помещений и/или машиномест как инвестиция

Функционал режима Simple: - Объекты, юниты (включая машиноместа и композитные юниты), арендаторы - Договоры, счета (NET + налог), оплаты, дебиторка - Базовые KPI и dashboard - Банковский канал: read-only dashboard для банка/инвестора - Налоговый модуль: выбор режима при настройке - Сценарное моделирование: предустановленные типы - Кадастровая стоимость: ручной ввод - Личный кабинет арендатора - Базовая воронка показов

Режим «Professional»¶

Для управляющих компаний и крупных собственников с портфелем объектов. Полный функционал:

Всё из режима Simple
Мультиобъект, мультивладение с разными налоговыми режимами в одном здании
Полная воронка показов (Авито, ЦИАН, источники, конверсия, аналитика)
Telegram-бот для управляющих (ежедневные отчёты)
Учёт инцидентов и намерений арендаторов
Полное сценарное моделирование + конструктор сценариев
CAPEX management, бюджетирование
Расширенная аналитика и BI
Банковский канал: для любого объекта в портфеле
Подготовка объекта к продаже (due diligence пакет)
Интерфейс акционера с автоматическими PDF-отчётами

Переключение: Simple → Professional при росте портфеля. Все данные сохраняются.

5. Market Intelligence Layer (рыночная аналитика)¶

5.1. Зачем этот слой существует¶

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

Какова реальная средняя ставка по офисам 100–200 м² в этой локации — не «по слухам и Циану», а по фактическим действующим договорам?
Какова медианная платёжная дисциплина арендаторов в сегменте ритейла? Какой процент задержек считается нормой, а какой — сигналом проблемы?
Как ведёт себя вакансия в данном районе — растёт, падает, стабилизируется?
Соответствует ли заявленный потенциальным заёмщиком бизнес-план реальной экономике сегмента?

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

Ключевые целевые аудитории слоя:

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

Стратегическое значение слоя:

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

Больше собственников → точнее аналитика
Точнее аналитика → ценнее для банков-партнёров
Ценнее для банков → банки рекомендуют (или требуют) от своих заёмщиков использовать Dominium
Больше заёмщиков подключается → ещё больше собственников

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

5.2. Уровни аналитики¶

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

Этаж 1. Дескриптивный — что есть на рынке.

Базовый уровень. Отвечает на вопросы вида «что происходит сейчас»: средние, медианы, перцентили ставок; уровни вакансии; распределения платёжной дисциплины; динамика во времени.

Запуск: в составе MVP. Требует минимально обезличиваемого объёма данных (k-anonymity ≥ 5 наблюдений от 3 собственников). Доступен всем ролям: собственникам, банкам-партнёрам, банкам-кредиторам, оценщикам.

Этаж 2. Диагностический — почему именно так.

Объясняет наблюдаемые на Этаже 1 закономерности. Отвечает на вопросы вида «ваш объект отстаёт от рынка на N% — почему?»: разложение факторов отклонения (сегмент, локация, состав арендаторов, структура договоров), выявление аномалий в платёжной дисциплине, сравнение сезонности.

Запуск: фаза 1.5, после стабилизации Этажа 1 и накопления исторических данных за минимум 12 месяцев. Доступен собственникам (объяснение по своему активу), банкам-кредиторам (объяснение по своему заёмщику).

Этаж 3. Предиктивный — что будет дальше.

Прогнозирует динамику показателей: ожидаемая вакансия в следующем квартале, ожидаемая платёжная дисциплина по сегменту, прогноз доходности.

Запуск: фаза 2. Требует критической массы данных — порядка 100+ объектов в одном региональном сегменте с историей не менее 12 месяцев. До достижения порога — этаж не активируется (любые прогнозы на малых данных будут давать слишком много шума и подорвут доверие к продукту).

Этаж 4. Прескриптивный — что делать.

Не просто прогноз, а рекомендация действия: «снизьте ставку на N% для повышения заполняемости», «пересмотрите условия договора с арендатором X для снижения риска неплатежа», «оптимальная стратегия для вашего сегмента — Y».

Запуск: возможен в будущем, по результатам Этажей 2 и 3. На текущем этапе фиксируется как направление развития. Конкретные сроки и условия запуска определяются по итогам наблюдения за работой Этажей 2-3.

Принципы фазирования:

Каждый следующий этаж строится на данных предыдущих.
Доверие к высоким уровням аналитики формируется через успешную работу низких. Если базовые бенчмарки регулярно ошибаются — предиктивные модели не имеют смысла.
Запуск этажа 3 и выше требует прохождения порога данных (определённое количество объектов, история, география). До порога модели не публикуются, чтобы не давать пользователям ложную уверенность.

5.3. Объём первой фазы (MVP)¶

В составе MVP запускается только Этаж 1 аналитического слоя — дескриптивный. Его объём сознательно ограничен, чтобы:

Сфокусироваться на самых востребованных банками и собственниками показателях.
Не растягивать MVP за счёт второстепенных метрик.
Накопить достаточный объём данных прежде, чем запускать Этажи выше.

Метрики, входящие в Этаж 1 MVP:

Ставка аренды (NET, рублей за м² в месяц): среднее, медиана, 25-й и 75-й перцентили.
Заполняемость / вакансия: текущий уровень в сегменте, динамика за последние 12 месяцев, средняя длительность простоя юнита.
Платёжная дисциплина: доля своевременных платежей, медианная задержка платежей, доля договоров с просрочкой более 30 дней.
Структура арендаторов в сегменте: распределение по типам бизнеса (укрупнённые категории, не ОКВЭД).

Срезы, по которым строятся метрики:

По типу объекта: офис, ритейл (стрит / в ТЦ), склад, производство.
По площади юнита: до 50 м², 50–100, 100–200, 200–500, 500+ м².
По локации: город / район (для крупных городов) / деловой кластер (Москва-Сити, БЦ-комплексы) / здание (микро-бенчмарк). В зависимости от плотности данных в конкретной зоне срез выбирается автоматически — нет смысла показывать улицу, на которой 2 собственника.
По типу договора: срочный / бессрочный, с индексацией / без, с обеспечительным платежом / без.

Что НЕ входит в Этаж 1 MVP:

Прогнозы любого вида (это Этаж 3, фаза 2).
Объяснения отклонений (это Этаж 2, фаза 1.5).
Рекомендации (Этаж 4, дальняя перспектива).
Срезы по индивидуальным условиям договоров (например, по конкретным формулам индексации) — слишком детально, нарушит k-anonymity на ранних объёмах данных.
Аналитика по операционным расходам и капитальным затратам — это отдельный сегмент данных, добавляется в фазе 2 после стабилизации основных метрик.

Минимальные требования к запуску:

В системе зарегистрированы минимум 30 собственников (порог для начала формирования полезных бенчмарков).
В каждом активно используемом сегменте — минимум 5 наблюдений от 3 разных собственников (k-anonymity).
История данных — минимум 3 месяца активного использования системы для формирования начальных трендов.

До достижения этих порогов аналитический слой может быть запущен в тестовом режиме для пилотных банков-партнёров с явной пометкой «данные неполные, для калибровки моделей».

5.4. Принципы обезличивания¶

Аналитический слой работает только с обезличенными агрегатами. Индивидуальные данные собственников и арендаторов не покидают операционный слой и не доступны ни одной из ролей в составе аналитики, за исключением случаев прямого договорного доступа (банк-кредитор к своему заёмщику, оценщик к оцениваемому объекту).

Базовое правило k-anonymity:

Любой агрегат показывается, только если в нём минимум 5 наблюдений от 3 разных собственников. Если в выборке меньше — агрегат не формируется и не показывается. Это защищает от вычисления индивидуальных значений методом исключения.

Дополнительное правило о доминировании:

Помимо k-anonymity, проверяется доля одного собственника в конкретном срезе. Если на одного собственника приходится более 50% наблюдений в сегменте — агрегат не формируется (даже если k-anonymity формально соблюдается). Это закрывает сценарий, при котором крупный собственник в небольшом здании или сегменте может вычислить ставки соседей по разности «общая средняя минус мои данные».

Микро-бенчмарк (по зданию) и макро-бенчмарк (по локации):

Те же правила применяются на обоих уровнях. Микро-бенчмарк работает только в зданиях, где соблюдены оба правила. В небольших зданиях с 1-2 собственниками микро-бенчмарк не формируется — это сознательное ограничение в пользу безопасности данных.

Что хранится в виде обезличенных агрегатов:

Численные показатели: средние, медианы, перцентили (25-й, 75-й, при необходимости — 10-й, 90-й).
Распределения: гистограммы по диапазонам.
Динамика: ряды значений по времени.

Что НЕ хранится в агрегатах:

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

Защита от косвенной деанонимизации:

Помимо двух базовых правил, применяются дополнительные меры:

Округление числовых значений — снижает точность, но защищает от тонкого reverse-engineering.
Скрытие крайних значений — минимум и максимум не показываются, если в выборке их даёт один собственник.
Минимум 3-месячная история для динамических рядов — нельзя «считать» поведение конкретного собственника по краткосрочным колебаниям.

Аудит и проверка обезличивания:

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

Linkage attack — попытка связать агрегаты с известными извне данными о собственниках.
Differencing attack — вычисление чужих значений по разности агрегатов до и после изменений.

Логи запросов к аналитическому слою сохраняются. При обнаружении подозрительных паттернов запросов (систематические попытки изолировать конкретного собственника) события фиксируются для расследования; в фазе 2 — автоматическая блокировка доступа до выяснения.

5.5. Управление согласием собственников (opt-in / opt-out)¶

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

Подписание согласия (opt-in):

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

Гранулярность согласия:

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

Базовый уровень (рекомендуется при регистрации): - Включение в макро-бенчмарки (агрегаты по локации и сегменту широко). - Включение в микро-бенчмарки (агрегаты по своему зданию).

Этот уровень составляет основу обмена «данные за бенчмарки» и рекомендуется к включению при регистрации. Покрывает 95% сценариев использования аналитического слоя.

Расширенный уровень (отдельное согласие на каждый пункт): - Использование в отчётах банков-партнёров для скоринга. - Использование в отчётах оценщиков, готовящих оценки для других объектов. - Использование в обучении предиктивных моделей (Этаж 3, фаза 2).

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

Отзыв согласия (opt-out):

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

Уведомления при изменениях:

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

152-ФЗ (Россия) — статья 21 определяет порядок прекращения обработки и уведомления субъектов при изменении условий.
GDPR (для сценариев международного развития) — статья 13/14 о предоставлении информации при изменении целей обработки.

Минимальный срок уведомления — 30 дней до вступления изменений в силу. Собственники обязаны подписать новую версию согласия. Если собственник не подписал — его данные временно исключаются из аналитики до момента подписания или явного отказа.

Юридическое оформление:

Конкретный текст согласия и правила его действия — в отдельном юридическом документе (legal/data-usage-policy.md, фаза разработки после MVP). На стадии MVP — рабочий черновик согласия, утверждённый юристом.

5.6. Источники данных¶

Аналитический слой работает на двух типах источников: первичных (операционные данные собственников в Dominium) и вторичных (внешние источники для калибровки и обогащения). Принципиально: основной вес и ценность аналитики — на первичных источниках.

Первичные источники:

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

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

Это данные, которые уже фактически произошли — заключённые договоры, проведённые платежи, реальные сроки простоев. Не оценочные, не публичные предложения, не «по аналогам».

Вторичные источники:

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

MVP: интеграция с Росреестром (кадастровая стоимость, правовая природа), уже есть в операционном слое — переиспользуется для аналитики.
Фаза 2: при необходимости — публичные агрегаты (Циан-агрегаты, отчёты консалтинговых агентств) для сверки наших бенчмарков с внешним рынком.
Фаза 3: специализированные источники (геоаналитика, демография локаций, трафик-данные) для предиктивных моделей.

Что НЕ является источником:

Пользовательский ввод «по аналогам». Собственник не может ввести «у меня примерно такая ставка, как у соседа» — в аналитику попадают только реально оформленные договоры с фактическими цифрами.
Оценочные данные оценщиков. Отчёты об оценке используют наши данные, а не наоборот.
Парсинг сайтов и публичных предложений в качестве основного источника. Только для сверки.

Версионирование источников:

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

Прозрачно показывать пользователю «бенчмарк построен на N договорах из K источников».
Воспроизводить агрегат на любую дату в прошлом (event sourcing гарантирует возможность ретроспективы).
При спорах ясно отделять данные Dominium от внешних дополнений.

5.7. Кто что видит — матрица доступа к аналитике¶

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

Матрица доступа:

Роль	Свои данные	Микро-бенчмарк (по зданию)	Макро-бенчмарк (по локации)	Срезы по сегментам
Собственник	✓ полные	✓ только своих зданий	✓ только своих локаций	✓ только своих сегментов
Банк-партнёр	—	—	✓ все локации	✓ все сегменты
Банк-кредитор	✓ только заёмщика	✓ здание заёмщика	✓ локация заёмщика	✓ сегмент заёмщика
Оценщик	✓ только оцениваемого объекта	✓ здание объекта	✓ локация объекта	✓ сегмент объекта
Инвестор	✓ только по предложению собственника	—	✓ локация предложения (фаза 2)	✓ сегмент предложения (фаза 2)
Управляющий (CEO УК, Asset Manager и др.)	✓ всех собственников по договору управления	✓ только зданий под управлением	✓ только локаций под управлением	✓ только сегментов под управлением
Арендатор	✓ только своих юнитов	—	—	—
Акционер	✓ всего портфеля	✓ зданий портфеля	✓ локаций портфеля	✓ сегментов портфеля

Принципы матрицы:

«Свои данные» — индивидуальные показатели, не обезличенные. Доступ определяется операционным слоем: договорные отношения, правоустанавливающие документы.
«Микро-бенчмарк» — обезличенный агрегат в пределах одного здания. Работает только если в здании достаточно собственников для k-anonymity. Если нет — агрегат не показывается.
«Макро-бенчмарк» — обезличенный агрегат по локации (район, деловой кластер, город). Базовое поле работы аналитического слоя.
«Срезы по сегментам» — обезличенные агрегаты по типу объекта и площади в выбранной локации.

Принцип «контекстного доступа»:

Банк-кредитор, оценщик и инвестор видят аналитику только в контексте конкретного актива, с которым у них договорная связь. Они не могут просматривать всю аналитику системы — для них агрегаты ограничены зданием/локацией/сегментом конкретного объекта.

Банк-партнёр видит макро-аналитику широко (все локации, все сегменты), потому что его бизнес-сценарий — скоринг потенциальных заёмщиков, которых он ещё не знает по конкретным объектам.

Принцип «информационной симметрии для собственника»:

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

5.8. Версионирование и доказуемость аналитики¶

Каждый агрегат, отдаваемый аналитическим слоем, имеет полный исторический след. Это критично для двух сценариев: ретроспективный анализ (восстановление картины «что видел банк на дату X») и разрешение споров (если решение было принято на основе бенчмарка, мы должны точно показать, что именно тогда показывалось).

Реализация через event sourcing:

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

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

Подпись агрегата:

Каждый показанный пользователю бенчмарк включает метаданные (невидимые в основном UI, но доступные при детальном запросе):

Дата и время формирования.
Хеш состояния данных, на которых построен агрегат.
Список идентификаторов источников (без раскрытия конкретных собственников — только агрегатные показатели количества).
Версия алгоритма обезличивания, использованного при формировании.

Внешняя верификация через блокчейн:

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

Принципиально: на блокчейн идёт только криптографический хеш, а не сами данные. Это:

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

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

Сценарии использования доказуемости:

Спор по решению банка. Заёмщик утверждает, что год назад банк выдал кредит на основе завышенной аналитики. Через журнал событий можно показать точно тот же агрегат, который видел банк в момент принятия решения, с подписью. С блокчейн-верификацией (фаза 2) — гарантия, что агрегат не редактировался после факта.
Аудит модели обезличивания. Внешний аудитор проверяет, что алгоритмы k-anonymity работали корректно на исторических данных, без вмешательства в журнал.
Регуляторные запросы. При необходимости (152-ФЗ, GDPR) можно предоставить полный аудит обработки данных конкретного собственника без раскрытия данных других участников.

Принципиально:

Журнал событий не редактируется задним числом. Если допущена ошибка в данных — она исправляется компенсирующим событием (запись «учётный факт X скорректирован событием Y»), а не переписыванием прошлого. Это гарантирует целостность исторических агрегатов до появления блокчейн-слоя; после появления блокчейн-слоя эта гарантия становится криптографически верифицируемой и не зависит от доверия к Dominium как платформе.

5.9. Бизнес-модель аналитического слоя¶

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

Монетизация по ролям:

Собственники участвующие в аналитике — доступ к бенчмаркам бесплатный в обмен на предоставление данных. Это базовая сделка «данные за аналитику», создающая критическую массу.
Собственники, не участвующие в аналитике — доступ к бенчмаркам закрыт. Нет участия — нет данных к нам, нет аналитики к ним.
Банки-партнёры — оплачивают доступ по модели подписки (с фиксированной ставкой) или per-query (за каждый сформированный отчёт). Конкретный выбор модели — за банком.
Банки-кредиторы — оплачивают доступ к мониторингу залога на объект, в составе сервисного пакета по кредиту. В простейшем сценарии: 1 кредит = 1 подключение, оплата встроена в кредитный тариф.
Оценщики — не платят напрямую (см. раздел 3), оплата встроена в гонорар по контракту с заказчиком оценки.
Инвесторы — модель определяется в фазе 2.

Этапы монетизации по фазам:

MVP: пилотный режим, минимум один банк-партнёр на льготных/бесплатных условиях для калибровки моделей и отработки процессов.
Фаза 2: подключение банков-партнёров и банков-кредиторов на коммерческой основе. Первые отчёты для оценщиков. Запуск блокчейн-слоя для верификации.
Фаза 3: запуск Этажа 3 (предиктивная аналитика) на премиум-тарифе. Расширение в смежные регионы. Возможный запуск API для b2b-клиентов (другие финтехи, страховые компании).

Принципы ценообразования:

Прозрачность для собственников — собственники должны видеть, что ценность, которую они генерируют через свои данные, возвращается им через аналитику и (опционально) через долевые механизмы.
Соответствие реальной ценности — стоимость доступа к аналитике для банка должна быть в разумной пропорции к экономии, которую банк получает от лучшего скоринга и мониторинга.
Защита от концентрации — ни один банк-партнёр не должен становиться эксклюзивным потребителем аналитики, чтобы не возникало ситуации «один банк диктует условия». Конкретные механизмы (квоты, антимонопольные правила в договорах) — фаза 2.

Долевая монетизация для собственников (фаза 3):

В долгосрочной перспективе рассматривается модель, при которой часть выручки от продажи аналитики банкам-партнёрам возвращается собственникам пропорционально их вкладу в данные. Это не зафиксировано как обязательство MVP/фазы 2, но обозначено как направление развития — отвечает на вопрос крупных собственников «зачем мне делиться данными бесплатно».

Что НЕ является источником монетизации:

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

6. Принятые ключевые решения¶

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

1. Многоуровневая платформа: операционка + рыночная аналитика¶

Изначально Dominium проектировался как операционная ERP-система для управления коммерческой недвижимостью. В ходе формирования продуктовой стратегии было принято решение расширить продукт до многоуровневой платформы: первый уровень — операционка для управляющих и собственников; второй уровень — обезличенная рыночная аналитика для банков-партнёров и оценщиков; третий уровень (фаза 2) — предиктивная аналитика. Альтернатива в виде «только операционная система» была отвергнута: она не использует уникальное преимущество — данные всех собственников в системе создают сетевой эффект и формируют дифференциатор, который операционные конкуренты не могут воспроизвести. Подробное описание уровней — в разделе 5.

ADR	Дата	Статус	Где детали
ADR-008	2026-04-28	Закреплено	`decisions/ADR-008-data-platform.md`

2. Модель видимости данных: чёткое разделение операционных и рыночных представлений¶

Доступ к данным в системе разделён на два контура с разными правилами. Операционный контур — индивидуальные данные конкретных собственников, договоров, арендаторов; доступ строится по договорным отношениям и правам собственности. Аналитический контур — обезличенные агрегаты, видимость которых определяется ролью пользователя (банк-партнёр видит макро-уровень, банк-кредитор — контекст своего заёмщика, оценщик — контекст оцениваемого объекта). Принципиальное правило: один и тот же банк может выступать и как партнёр (макро-аналитика), и как кредитор (мониторинг конкретного залога) — это разные контракты с разными правами. Альтернатива «один общий dashboard для банков» отвергнута: она смешивает разные сценарии использования и нарушает принципы обезличивания.

ADR	Дата	Статус	Где детали
ADR-007	2026-04-28	Закреплено	`decisions/ADR-007-data-scope-model.md`

3. Двойная иерархия: юнит может быть собран из частей разных ЕГРН¶

Один сдаваемый юнит (например, торговое помещение в стрит-ретейле) в реальной коммерческой недвижимости может физически объединять части нескольких ЕГРН-объектов, при этом части могут принадлежать разным собственникам и быть оформлены на разных правовых основаниях. Зафиксирована двухуровневая модель данных: операционный юнит — единица сдачи в аренду; ЕГРН-объекты — единицы юридического владения; связь между ними хранится в отдельной таблице с долями площади и стоимости. Альтернатива «один юнит = один ЕГРН» отвергнута: она не покрывает реальные кейсы из портфеля (Кластер 73, Нововатутинская, дополнительный кейс «один ЕГРН проходит через несколько помещений»). Решение прошло валидацию на четырёх реальных объектах.

ADR	Дата	Статус	Где детали
ADR-005	2026-04-27	Закреплено (расширено 2026-04-28)	`decisions/ADR-005-dual-hierarchy.md`

4. Единая модель контрагента: одна сущность, разные роли¶

Один и тот же субъект (юридическое лицо или человек) в системе может одновременно выступать в нескольких ролях: собственник одного объекта, арендодатель по одному договору, арендатор по другому, посредник в субаренде. Зафиксирована единая модель Контрагент для всех ролей; конкретная роль определяется не атрибутом сущности, а контекстом договора, в котором эта сущность участвует. Альтернатива «отдельные сущности Собственник, Арендатор, Конечный пользователь» отвергнута: она дублирует одни и те же реквизиты (ИНН, реквизиты, контакты) при изменении роли и не отражает реальность, где субъект меняет роли по мере развития бизнеса. Решение прошло валидацию на реальных кейсах: одно юрлицо в разных ролях, цепочки субаренды (ООО → ИП → конечный арендатор), один арендатор в нескольких юнитах, мультивладение объектами.

ADR	Дата	Статус	Где детали
ADR-006	2026-04-27	Закреплено	`decisions/ADR-006-party-model.md`

5. Журнал событий с цифровыми подписями: восстановление картины на любую дату прошлого¶

В системе никакие данные не удаляются и не редактируются задним числом — каждое изменение (новый договор, индексация, расторжение, смена собственника, отзыв согласия на аналитику) фиксируется как отдельное событие с временной меткой и цифровой подписью. Текущее состояние любого объекта — это проекция всех событий до текущего момента; на любую дату в прошлом картина восстанавливается точно так, как её видели пользователи тогда. Это критично для трёх сценариев: разрешение споров (банк опирался на бенчмарк год назад — какой именно?), регуляторные запросы (152-ФЗ, GDPR — полный аудит обработки данных), и блокчейн-верификация (фаза 2 — независимое от Dominium доказательство неизменности). Обычный подход — хранить текущее состояние и отдельный лог изменений — отвергнут: при таком решении возникают две версии правды (актуальные данные + история), которые могут расходиться при программных ошибках. Event sourcing решает это, делая лог единственным источником правды.

ADR	Дата	Статус	Где детали
ADR-003	2026-04-27	Закреплено	`decisions/ADR-003-event-sourcing.md`

6. NET-pricing: все суммы хранятся без налогов; налоговый слой — отдельный модуль¶

В системе все денежные суммы — ставки, счета, начисления — хранятся в формате NET (без НДС, без других налогов), а налоги вычисляются отдельным модулем при формировании счетов и отчётов. Это позволяет: работать с одним и тем же договором при изменении налогового режима собственника (переход с УСН на ОСНО), корректно сравнивать ставки между объектами с разными налоговыми режимами, поддерживать мультиюрисдикционность (Россия, СНГ, другие страны) без переделки модели данных. Альтернатива «хранить gross-суммы (с налогом) как в большинстве 1С-систем» отвергнута: при изменении налогового режима или ставки НДС нужно пересчитывать весь исторический массив договоров, что нарушает принцип неизменности журнала событий и создаёт риски ошибок.

ADR	Дата	Статус	Где детали
ADR-002	2026-04-27	Закреплено	`decisions/ADR-002-net-pricing.md`

7. Автоматическая интеграция с Росреестром: кадастровая стоимость как первичный источник¶

Кадастровая стоимость объекта недвижимости — обязательный параметр для расчёта налога на имущество, для оценки залогового потенциала (LTV), для построения сравнительных бенчмарков. Зафиксировано: кадастровая стоимость подгружается автоматически из Росреестра по кадастровому номеру при заведении объекта, и обновляется при каждой переоценке (обычно раз в 4 года). Параллельно поддерживается расчёт LTV тремя методами: по кадастровой стоимости, по доходному подходу (NOI / cap rate), по сравнительному подходу (через рыночные бенчмарки аналитического слоя). Альтернатива «вручную вводить кадастровую стоимость и обновлять» отвергнута: на портфелях из десятков объектов это создаёт операционную нагрузку и риск устаревших данных, что критично для банков, использующих эти данные при принятии кредитных решений.

ADR	Дата	Статус	Где детали
ADR-004	2026-04-27	Закреплено	`decisions/ADR-004-cadastral-api.md`

8. Технологический стек: open-source, blockchain-ready, без vendor lock-in¶

В качестве технологической основы зафиксированы open-source компоненты с принципом отсутствия vendor lock-in: PostgreSQL для транзакционной части, ClickHouse для аналитической, Python/FastAPI для backend, React для frontend. Архитектура blockchain-ready — журнал событий с цифровыми подписями технически готов к публикации хешей в публичный блокчейн (фаза 2, см. раздел 5.8). Альтернативы рассматривались: проприетарные стеки (Microsoft, Oracle, 1С) отвергнуты из-за лицензионных рисков и привязки к одному вендору; облачные управляемые сервисы (Yandex Cloud, Selectel) — допустимы для развёртывания, но не как архитектурная основа, чтобы сохранить возможность миграции. Конкретные версии и принципы развёртывания — в разделе 17.

ADR	Дата	Статус	Где детали
ADR-001	2026-04-27	Закреплено	`decisions/ADR-001-tech-stack.md`

9. AI-Native архитектурный слой¶

Статус: в работе, рамка зафиксирована, наполнение продолжается.

В чём вопрос был. В версии 2.1 ТЗ AI/ML фигурировал одной строкой в таблице модулей — общим пунктом «Churn, vacancy прогноз, аномалии» в Фазе 2. Это типичная для классических ERP трактовка — AI как набор изолированных фич, прикрученных к существующей системе. В ходе обсуждения позиционирования продукта (на фоне общей слабости использования AI в сегменте управления коммерческой недвижимостью) стало ясно: для Dominium это упущенная возможность. Архитектура с Event Sourcing (ADR-003), единой моделью контрагента (ADR-006), двойной иерархией (ADR-005) и двухуровневой платформой (ADR-008) — идеальный субстрат для AI-Native подхода. Каждое событие в системе автоматически становится тренировочным сигналом без дополнительного ETL — это нативное преимущество, которое классические ERP с CRUD-базами получить не могут.

Варианты, которые рассматривали.

Вариант A. Оставить AI/ML как было — общий пункт в Фазе 2. Минус: не использует архитектурные преимущества Dominium, упускает окно AI-Native позиционирования. Document AI и AI-копилот в Telegram — это снятие барьеров внедрения, не «фича на потом»: без них миграция с Excel/1С остаётся мучительной, Telegram-бот превращается в очередную форму со списками.
Вариант B, выбранный. Выделить AI/ML в отдельный архитектурный слой на Этапе 0 с разделением на две категории. AI-Native MVP — Document AI для импорта договоров, AI-копилот в Telegram-боте управляющего, LLM-обёртка над конструктором сценариев. Работают на любом масштабе данных, включаются с MVP. AI-Enhanced — уточнение Этажа 3 ADR-008 (predictive Tenant Health Score, vacancy forecasting, anomaly detection, smart alerts ranking, авто-комментарии для банка). Открываются при достижении критической массы данных (тот же порог, что Этаж 3 в ADR-008).
Вариант C. Спроектировать AI-первый продукт — каждое действие через LLM, классические интерфейсы как fallback. Минус: в финансовом домене (договоры, начисления, банковский мониторинг) необходима детерминированность и объяснимость. AI-первый подход создаёт риски галлюцинаций. Гибридная модель (AI как слой над детерминированной системой) — правильный баланс для B2B продукта.

Что выбрано — Вариант B.

Почему. AI-Native MVP формирует «магические моменты» для пользователей с первого дня и снимает главный барьер внедрения (Document AI снимает мучительную ручную миграцию). AI-Enhanced встраивается в уже зафиксированный Этаж 3 ADR-008 — архитектурно чисто, без дублирования. Решение опирается на 6 принципов: AI как слой, провайдер-агностичность, human-in-the-loop, объяснимость, деградация без AI, защита персональных данных.

Что это означает на практике. Архитектура MVP получает выделенный слой инференса (отдельный сервис, изолированный от основного backend), готовность к feature store и vector database (решение по конкретным реализациям — на Этапе 1 или Этапе 2). Конкретный LLM-провайдер не выбирается сейчас намеренно (ADR-010): индустрия меняется месячными циклами, фиксировать вендора в апреле 2026 для модулей, которые будут разрабатываться через 6–9 месяцев, преждевременно. Слой инференса проектируется провайдер-агностичным — смена LLM становится конфигурационной операцией.

ADR	Дата	Статус	Где детали
ADR-009	2026-04-29	Принят	`decisions/ADR-009-ai-architecture-layer.md`
ADR-010	2026-04-29	Открыт	`decisions/ADR-010-llm-provider.md`

7. Модель данных: юридическая и операционная топология¶

5.1 Двойная иерархия объектов¶

Юридическая иерархия (от права собственности):

Земельный участок → Здание (адрес) → Объект ЕГРН (кадастровый номер, площадь, собственник). Каждый объект ЕГРН: кадастровый номер, площадь по ЕГРН, собственник (ООО / ИП / физлицо), тип права, налоговый режим собственника, кадастровая стоимость (см. раздел 7.7).

Операционная иерархия (от аренды):

Портфель → Объект (здание / земельный участок) → Зона → Юнит (арендная единица).

Юнит — универсальная арендная единица любого типа. Всё, что может быть предметом договора аренды, является юнитом:

Помещение (офис, торговля, производство, склад, общепит)
Машиноместо (отдельное или часть композита)
Земельный участок (часть территории)
Рекламное место (фасад, лайтбокс, digital-экран, медиафасад)
Антенное место (крыша, мачта)
Место под вендинг / банкомат
Временное торговое место (островок в МОП)
Открытая площадка
Складская ячейка, коворкинг-место (Фаза 2)

Зона — логическая группировка юнитов внутри объекта:

Этаж (для помещений и машиномест)
Крыша (для антенных мест)
Фасад — сторона: север / юг / восток / запад (для рекламных мест)
МОП конкретного этажа (для вендинга, островков)
Территория / двор (для земельных участков и открытых площадок)
Паркинг — уровень (для машиномест)

Этот подход позволяет: использовать единый Billing Engine, единый Contract Engine и единый набор метрик для всех типов юнитов. Vacancy, доходность и другие KPI рассчитываются как по типу юнита (отдельно помещения, отдельно рекламные места), так и в сумме по объекту.

Юнит может быть: - Простым — один объект (помещение, одно машиноместо, одно рекламное место) - Композитным — собранным из нескольких объектов ЕГРН и/или долей МОП

Связка иерархий:

Таблица соответствий «Юнит ↔ Объекты ЕГРН» с долей, типом использования и площадью.

5.2 Модель владения¶

Единственный собственник — одно лицо владеет зданием
Мультивладение — несколько собственников, каждый со своим ЕГРН и налоговым режимом
Фондовая структура — набор юрлиц, объединённых инвестиционной структурой
Стрит-ретейл — одно помещение, один собственник

5.3 Субаренда и цепочки прав¶

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

Собственник (ООО) → ИП → Конечный арендатор (налоговая оптимизация)
Собственник → УК → Арендатор (управление через УК)
Любые другие схемы, которые могут возникнуть в будущем

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

5.4 Жизненный цикл юнита: создание, разделение, объединение, перекомпоновка¶

Юнит — такой же живой объект, как договор и ЕГРН. Собственник или управляющий может менять арендную нарезку объекта. При этом ЕГРН может не меняться — меняется только операционная структура.

Операции с юнитами:

Операция	Что происходит	Пример	Влияние на договоры
Создание (Create)	Новый юнит из одного или нескольких объектов ЕГРН / долей МОП	4 машиноместа + 40 м² МОП = 1 юнит	Юнит готов к заключению договора
Разделение (Unit Split)	Один юнит → несколько юнитов	Юнит из 4 м/м → 4 отдельных юнита	Старый договор закрывается. Новые договоры на каждый
Объединение (Unit Merge)	Несколько юнитов → один юнит	2 офиса по 50 м² → 1 офис 100 м²	Старые договоры закрываются. Новый договор на объединённый
Перекомпоновка (Recompose)	Изменение состава композитного юнита	Из юнита убрали 1 м/м, добавили часть МОП	Доп. соглашение к договору
Нарезка (Partition)	Одно помещение → несколько юнитов (физическое разделение)	500 м² → два по 250 м²	Старый договор закрывается. Новые на каждую часть
Перепланировка (Resize)	Изменение границ юнита без разделения	100 м² → 130 м² за счёт соседнего	Доп. соглашение

Принципы обработки операций с юнитами:

Версионирование: каждое изменение юнита создаёт новую версию с датой
Связь с ЕГРН сохраняется: при разделении юнита каждый новый юнит наследует привязку к объектам ЕГРН (пропорционально)
Каскад на договоры: система предлагает варианты — закрыть старый договор и создать новые, или оформить доп. соглашение
Каскад на метрики: vacancy, средневзвешенная ставка, доходность пересчитываются мгновенно
Уведомления: алерт управляющему, арендатору (если затронут), собственнику
Аудит: полная история всех операций с юнитом
Визуализация: на поэтажном плане изменения отображаются сразу после операции

5.5 Жизненный цикл владения: транзакции с правами собственности¶

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

Типы транзакций:

Транзакция	Что происходит	Влияние на систему
Разделение (Split)	Один ЕГРН → два и более ЕГРН	Создание новых ЕГРН. Перебиндинг юнитов и договоров. Запрос новой кадастровой стоимости для каждого ЕГРН.
Частичная продажа	Выделенный ЕГРН → новому собственнику	Смена собственника. Возможна смена налогового режима. Договоры аренды сохраняются.
Полная продажа	Весь объект → новый собственник	Смена собственника, налогового режима. Все метрики пересчитываются.
Объединение (Merge)	Несколько ЕГРН → один ЕГРН	Объединение объектов. Перебиндинг юнитов.
Распределение между акционерами	Фонд распределяет объекты между участниками	Серия Split + Transfer
Смена юрлица	Объект переводится с одного ООО на другое	Смена юридического собственника. Возможна смена налогового режима.

Принципы: - Атомарность: транзакция либо выполняется полностью, либо не выполняется - История: каждый объект ЕГРН хранит полную историю владения - Каскад: автоматически обновляются арендодатель в действующих договорах, налоговый режим, все зависимые метрики - Непрерывность аренды: ст. 617 ГК РФ — договоры продолжают действовать при смене собственника - Уведомления: автоматические алерты всем затронутым ролям - Влияние на банк: LTV и DSCR пересчитываются. Кадастровая стоимость пересчитывается для каждого ЕГРН отдельно.

5.6 Типы арендных объектов (расширяемый справочник)¶

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

Полный каталог типов арендных объектов:

Тип объекта	Описание	Особенности расчёта аренды	Фаза
Помещение	Офис, торговля, производство, склад, общепит	Ставка за м² / месяц + все типы расчёта	MVP
Машиноместо	Крытая/открытая парковка	Ставка за единицу / месяц или за м²	MVP
Земельный участок	Сдача земли: парковка, торговля, вышки связи	Ставка за м² или за участок. Атрибуты: кадастровый №, категория, ВРИ	MVP
Рекламное место	Фасад, крыша, стены МОП, digital-экраны, лайтбоксы, медиафасад	Ставка за единицу / месяц	MVP
Антенное место / БС	Крыша, мачта, площадка для операторов связи	Ставка за единицу. Долгосрочные контракты	MVP
Вендинг / банкоматы	Место 1–2 м²	Ставка за место / месяц. Возможен % от выручки	MVP
Временное торговое место	Островок в МОП, сезонная точка, pop-up	Ставка за место. Краткосрочная / сезонная	MVP
Открытая площадка	Часть территории: летнее кафе, ярмарка	Ставка за м² или за площадку. Сезонная аренда	MVP
Навигационные элементы	Стелы, указатели на территории	Ставка за единицу	MVP
Складская ячейка / бокс	Self-storage	Ставка за единицу. Возможна почасовая / посуточная	Фаза 2
Коворкинг-место	Рабочее место, не помещение целиком	Ставка за место. Почасовая / подневная / помесячная	Фаза 2

Архитектурный принцип:

Каждый тип арендного объекта определяется набором атрибутов:

Базовые (общие для всех): ID, название, привязка, площадь, статус
Специфические (зависят от типа): для помещения — назначение, высота, отделка; для земли — кадастровый №, категория, ВРИ; для рекламы — тип конструкции, размер, сторона
Единица тарификации: м², место, единица, участок
Применимые типы расчёта аренды

Справочник типов расширяемый: администратор может добавить новый тип без привлечения разработчиков.

5.7 Кадастровая и рыночная оценка объектов¶

Модуль хранения и автоматического получения стоимостных оценок объектов недвижимости для расчёта LTV, аналитики собственника и банковского мониторинга.

Три типа стоимости¶

Тип	Источник	Обновление	Применение
Кадастровая	Росреестр (автоподгрузка по кадастровому номеру)	При пересмотре (раз в 3-5 лет)	LTV (baseline), налог на имущество
Рыночная	Отчёт оценщика (ручной ввод + загрузка скана)	При заказе оценки	LTV (точная), продажа, залог
Расчётная (implied)	Автоматически: NOI / Cap Rate	Real-time	Экспресс-оценка, dashboard собственника

Интеграция с Росреестром (Фаза 2)¶

Endpoint: Публичная кадастровая карта API (pkk.rosreestr.ru)
Метод: GET по кадастровому номеру
Данные: кадастровая стоимость, дата оценки, площадь, адрес, категория
Формат: JSON
Ограничения: Rate limiting, нет гарантированного SLA → fallback-стратегии

Альтернативные источники¶

API ФНС (ФИАС) — справочные данные
Парсинг rosreestr.gov.ru — fallback
Коммерческие API (DaData, Контур.Фокус) — для обогащения данных

Стратегия подгрузки¶

При добавлении объекта ЕГРН → автозапрос кадастровой стоимости
Ежемесячная проверка обновлений (cron job)
При изменении кадастрового номера (split/merge ЕГРН) → перезапрос
Fallback: ручной ввод если API недоступен

Версионирование оценок¶

Каждая новая оценка создаёт новую запись. Старая помечается is_current = false. Полная история оценок доступна для аудита и трендов.

Влияние на банковский dashboard¶

LTV расчёт (расширенная формула):

LTV = Остаток_кредита / Стоимость_залога

Стоимость_залога — выбирается банком из трёх методов:
  - Консервативный: MIN(Кадастровая, Рыночная)
  - Стандартный: Рыночная (если есть актуальный отчёт оценщика)
  - Индикативный: Расчётная (NOI / Cap Rate)

Алерты банка (расширенные):

LTV > 75% (жёлтый) / > 90% (красный) — стандартные пороги
Кадастровая стоимость изменилась > 10% → алерт
Рыночная оценка устарела (> 12 мес.) → алерт «требуется переоценка»
Implied стоимость упала > 15% от рыночной → алерт расхождения

Dashboard собственника (расширение)¶

Implied стоимость в реальном времени (NOI / Cap Rate)
График: динамика стоимости (кадастровая vs рыночная vs implied) во времени
Сценарное моделирование: «Как изменится implied стоимость при vacancy +10%?»

Фазность¶

MVP: - Ручной ввод кадастровой и рыночной стоимости - Автоматический расчёт implied стоимости (NOI / Cap Rate) - LTV расчёт с тремя методами - Алерты по LTV и устареванию оценки

Фаза 2: - Автоподгрузка из Росреестра по API - Автообновление по cron - Интеграция с коммерческими API (DaData) - История оценок с трендами

8. Функциональная архитектура (модули)¶

Модуль	Описание	MVP	Фаза 2
Ядро данных	Двойная иерархия, реестр ЕГРН, модель владения	✓
Жизненный цикл владения	Split, продажа, объединение, реструктуризация, распределение	✓
Contract Engine	«Живой договор»: условия, timeline, версионирование	✓
Billing Engine	6 типов аренды, сервисные сборы, счётчики	✓
Налоговый модуль	РФ режимы (ОСНО, УСН, ОЭЗ). Подключаемые модули	✓ (РФ)	СНГ, другие
Индексация	Фикс%, курс, условная (ИПЦ > порога)	✓
Дебиторка и платежи	Учёт, aging, пени, разбивка по категориям (аренда / эксплуатация / коммуналка / парковка / реклама)	✓
Leasing Pipeline	CRM-воронка: запрос → показ → КП → согласование → договор → заезд. Источники: Авито, ЦИАН, сайт, звонок, сарафан	✓
Tenant Health Score	Автоскоринг арендатора (0–100)	✓
Manager Reports	Ежедневные отчёты управляющих (5 блоков)	✓
Telegram-бот	Утренняя рассылка (09:00), сбор отчётов, антисаботаж (1 клик «Ничего не произошло»), SMS fallback (Фаза 2)	✓	SMS fallback
Incidents	Учёт инцидентов: описание, severity, статус, история	✓
Tenant Intentions	Намерения арендаторов: съезд / расширение / сокращение	✓
Showings (воронка показов)	Все показы с источником, контактом, результатом. Аналитика конверсии	✓
Alerts engine	Триггеры: просрочка >15 дней, превышение депозита, намерение, заполненность <80%, пропущенные отчёты	✓
Кадастровая стоимость	Хранение, история, расчёт implied	✓ (ручной ввод)	Автоподгрузка из Росреестра
Dashboard: Управляющий	Заполняемость, ставки, дебиторка, алерты, заявки	✓
Dashboard: Собственник	P&L, NOI, доходность, KPI, портфель, implied стоимость	✓
Dashboard: Акционер	Read-only сводка: выручка, задолженность, заполненность, тренды	✓
Dashboard: Банк/Инвестор	DSCR, LTV (3 метода), vacancy, ковенанты, кадастр	✓
PDF-отчёты для акционера	Автогенерация ежемесячного PDF-отчёта 1-го числа	✓
ЛК Арендатора	Счета (NET+налог), задолженность, пени, заявки, индексация	✓
Сценарное моделирование	Предустановленные + конструктор (sandbox)	✓	AI-расширение
Учёт счётчиков	Ручной ввод, расчёт, коэффициенты	✓	АСКУЭ
Эксплуатация (заявки)	Заявки, статусы, реакция, привязка к плану здания	✓
CAPEX Management	Планирование, согласование, контроль	✓ (базовый)	Расширенный
Бюджетирование	Годовой бюджет, план-факт, отклонение >10% → алерт	✓	3–5 лет
Дополнительные потоки доходов	Медиафасад, навигация, антенные места — отдельные revenue streams	✓
Импорт банковских выписок	CSV-импорт, разнесение платежей по договорам	✓
Интеграция 1С	Счета, акты, сверки, НДС	✓
Интеграция Авито	Импорт лидов в воронку показов	✓
Интеграция ЦИАН	Импорт лидов в воронку показов	✓
ЭДО	Диадок / СБИС		✓
CRM расширенная	Отношения с арендаторами и лидами		✓
ППР и оборудование	Регламенты ТО, плановые замены		✓
ESG	Энергоэффективность, sustainability		✓
AI/ML слой	См. раздел 1 и решение №9 раздела 6. AI-Native (Document AI, Telegram-копилот, LLM-сценарии) — в MVP; AI-Enhanced (predictive THS, vacancy forecast, anomaly detection, smart alerts ranking, авто-комментарии банку) — расширение Этажа 3 (Фаза 2+)	✓ (AI-Native)	✓ (AI-Enhanced)
Benchmarking	Сравнение с рынком		✓
Document AI (импорт договоров)	Извлечение полей из PDF/сканов существующих договоров → автозаполнение «живого договора» с проверкой человеком	✓	Расширенный (поддержка большего числа форматов)
AI-копилот в Telegram	Распознавание свободного текста и голосовых сообщений в Manager Reports / Showings / Incidents / Tenant Intentions с подтверждением	✓
LLM-обёртка над конструктором сценариев	Естественный язык → параметры sandbox → расчёт + текстовый разбор результата	✓
Мультивалюта	USD/EUR, курс ЦБ		✓
Онлайн-оплата	Эквайринг из ЛК арендатора		✓
Due Diligence пакет	Подготовка объекта к продаже		✓
Нативное мобильное приложение	iOS + Android (React Native)		✓

9. Модель «живого договора»¶

Договор аренды — центральный объект системы. Не статичная запись, а объект с временной осью, условиями, событиями и прогнозами.

Структура¶

Стороны: арендодатель (с налоговым режимом), арендатор, конечный пользователь, ссылка на родительский договор
Объект: юнит(ы), площадь, этаж, привязка к ЕГРН
Timeline условий (каждое действует в определённый период):
Базовая ставка (NET) — может меняться по ступенчатому графику
% от оборота (формула, минимум, период отчётности)
Эксплуатационный платёж (руб./м²)
Каникулы: rent-free (аренда = 0, эксплуатация платится) и полные (все = 0)
Индексация: формула, периодичность, триггеры, ceil/floor
Налог: рассчитывается автоматически по режиму арендодателя
Сроки: начало, окончание, пересмотр, break options
Депозит: сумма, условия возврата, зачёт
Пени: формула, grace period
Статус: черновик → согласование → подписан → активен → пересогласование → завершён → архив
Версионирование: каждое изменение = новая версия с датой вступления в силу
Автособытия: окончание через 90/60/30 дней, дата пересмотра, нарушение условий
Документы: сканы, доп. соглашения, переписка
Намерения арендатора: связь с модулем Tenant Intentions

10. Billing Engine: типы расчётов¶

Все ставки хранятся и рассчитываются в NET (без налога). Налог добавляется отдельным модулем при формировании счёта.

Тип	Формула (NET)	Пример
Фиксированная ставка	Ставка × Площадь	1 200 руб./м² × 100 м² = 120 000 NET
Фикс + % от оборота	max(Фикс × Площадь, Оборот × %)	max(120 000, 5 000 000 × 5%) = 250 000 NET
Ступенчатая	Ставка по графику × Площадь	Мес 1–3: 800, мес 4–6: 1000, мес 7+: 1200
Turnover-only	Оборот × %	5 000 000 × 6% = 300 000 NET
Краткосрочная	Суточная ставка × Дни	5 000/день × 14 = 70 000 NET
Сезонная	Ставка по сезону × Площадь	Лето: 1500, зима: 900 руб./м²

Дополнительные начисления (отдельные строки в счёте):¶

Эксплуатационный платёж: ставка руб./м² (NET)
Электричество: (текущее − прошлое показание) × тариф × коэффициент
Вода: аналогично
Отопление: по факту или пропорционально
Парковка: отдельная категория
Дополнительные сервисы: клининг, охрана и т.д.

Категоризация дебиторки¶

Дебиторская задолженность хранится с разбивкой по категориям для аналитики: - Аренда (rent) - Эксплуатационный платёж (utilities/expl) - Коммунальные услуги (communal) - Реклама (advertising) - Парковка (parking) - Пени (penalty)

11. Налоговый модуль¶

Архитектурный принцип: ставки NET → налог как подключаемый модуль¶

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

Почему так:

В одном здании разные собственники могут быть на разных режимах
В цепочке субаренды каждое звено имеет свой режим
Ставки и правила меняются (18% → 20%, могут измениться снова)
За пределами РФ — другие налоговые системы
Управленческая аналитика (NOI, доходность) считается по NET

Налоговый пакет «Россия» (MVP)¶

Режим	НДС	Логика в счёте	Кто применяет
ОСНО	Да (по умолчанию 20%)	NET + НДС = GROSS	ООО, крупные ИП
УСН 6% (доходы)	Нет	NET = GROSS, «Без НДС»	ИП, малые ООО
УСН 15% (доходы−расходы)	Нет	NET = GROSS, «Без НДС»	ИП, малые ООО
Без системы (физлицо)	Нет	NET = GROSS	Физлица-арендодатели
Режим ОЭЗ / ТОСЭР	Специальные ставки	NET + спец. НДС = GROSS	Резиденты ОЭЗ

Планируемые налоговые пакеты (Фаза 2)¶

Казахстан: НДС 12%, упрощённый режим
Узбекистан: НДС 12%, единый налоговый платёж
ЕС (VAT): реверс-чардж, различные ставки
Другие юрисдикции: подключаются через конфигурацию

Модель данных налогового модуля¶

У каждого арендодателя — атрибут «Налоговый профиль»:

Юрисдикция (Россия / Казахстан / ...)
Тип режима (ОСНО / УСН 6% / УСН 15% / ОЭЗ / Custom)
Ставка налога (конфигурируемая)
Дата начала действия (версионируется)
Признак «плательщик НДС»

Формирование счёта¶

Строка 1: Аренда         — 120 000 руб. (NET)
Строка 2: Эксплуатация   —  26 400 руб. (NET)
Строка 3: Электричество  —  15 000 руб. (NET)
Итого NET:                 161 400 руб.
НДС 20%:                    32 280 руб. (если ОСНО) или 0 (если УСН)
Итого GROSS:               193 680 руб. (ОСНО) или 161 400 руб. (УСН)

12. Индексация и условные формулы¶

Модель 1: Фиксированный процент¶

Новая ставка (NET) = Текущая × (1 + X%). Пример: +7% ежегодно с 1 января.

Модель 2: Привязка к курсу валюты¶

Ставка (NET) = Базовая в валюте × Курс ЦБ. MVP — ручной ввод. Фаза 2 — API ЦБ.

Модель 3: Условная индексация (ИПЦ с порогом)¶

ЕСЛИ ИПЦ > Порог → ставка × ИПЦ; ИНАЧЕ → ставка × фикс%. Реализуется через rule engine.

Общие требования¶

Версионирование ставок: каждое изменение с датой вступления в силу
Предварительный расчёт: система показывает будущую ставку до момента индексации
Алерт управляющему за N дней до даты индексации
Алерт арендатору за N дней до даты индексации (через ЛК и/или email/SMS)
Массовая индексация: применение формулы ко всем договорам объекта
Аудит: полная история изменений ставок
Все индексации применяются к NET-ставкам, налог пересчитывается автоматически

13. Система метрик и KPI¶

Все финансовые метрики рассчитываются на основе NET-сумм. Отдельно доступны GROSS-метрики для бухгалтерской отчётности.

Операционные метрики (управляющий)¶

Метрика	Формула	Разрезы
Vacancy Rate	∑ Площадь_вакант / ∑ Площадь_всего × 100%	Здание, этаж, зона, тип юнита
Collection Rate	∑ Оплачено / ∑ Начислено × 100%	Период, объект, арендатор
Дебиторка (aging)	Группировка: текущая, 1–30, 31–60, 61–90, 90+	Арендатор, объект, категория
Средневзвешенная ставка	∑(Ставка × Площадь) / ∑ Площадь	Этаж, зона, тип (NET)
Tenant Health Score	Алгоритм: платежи, стаж, стабильность (0–100)	Арендатор
Lease Expiry Profile	Количество и площадь истекающих по месяцам	24 мес.
WALE	∑(Остаток_срока × Доход) / ∑ Доход	Объект, портфель
Retention Rate	Продлившие / Все_истёкшие × 100%	Период, объект
Time-to-Lease	Среднее(Подписание − Освобождение)	Объект, тип
Conversion Funnel	Конверсия по этапам воронки показов	Источник, менеджер
Manager Compliance	% сданных вовремя ежедневных отчётов	Управляющий, период

Стратегические метрики (собственник)¶

Метрика	Формула	Разрезы
NOI	Доход_аренды (NET) − OPEX	Объект, собственник
NOI Yield	NOI / Стоимость × 100%	Объект
Общий cashflow	∑ Все_поступления (NET)	Объект, собственник
OPEX Ratio	OPEX / Доход (NET) × 100%	Объект
CAPEX план-факт	Факт / План	Объект, проект
Implied стоимость м²	NOI / Cap_Rate / Площадь	Объект
Дополнительные доходы	Медиафасад, навигация, антенны	Объект, тип

Метрики акционера¶

Метрика	Формула	Период
Выручка	∑ Поступления (NET)	Месяц, тренд за 12 мес.
Задолженность	∑ Дебиторка (текущая)	На дату
Заполненность	100% − Vacancy Rate	На дату, тренд
Дополнительные доходы	Медиафасад, навигация, антенны	Месяц

Банковские метрики¶

Метрика	Формула	Алерт
DSCR	NOI / Платёж_по_кредиту	< 1.2 жёлтый, < 1.0 красный
LTV (консервативный)	Остаток_кредита / MIN(Кадастровая, Рыночная)	> 75% жёлтый, > 90% красный
LTV (стандартный)	Остаток_кредита / Рыночная	> 75% жёлтый, > 90% красный
LTV (индикативный)	Остаток_кредита / Implied (NOI/Cap)	> 75% жёлтый, > 90% красный
Vacancy Rate	См. выше	> 15% жёлтый, > 30% красный
Collection Rate	См. выше	< 90% жёлтый, < 80% красный
Кадастровая динамика	Δ Кадастровая стоимость	> 10% алерт
Возраст оценки	Сейчас − Дата_рыночной_оценки	> 12 мес. — требуется переоценка
Расхождение Implied vs Рыночная	(Implied − Рыночная) / Рыночная	< −15% алерт
Covenant Status	Проверка ковенантов	Нарушение — красный

Метрики аналитического слоя¶

Помимо метрик операционного слоя, MVP отслеживает базовые показатели работы рыночной аналитики:

Покрытие аналитики:

Количество собственников, давших согласие на участие в аналитике (минимальный порог запуска: 30).
Количество сегментов с достаточным покрытием для формирования бенчмарков (k-anonymity ≥ 5 наблюдений от 3 собственников).
Доля географических зон (район / деловой кластер / здание), где работает микро-бенчмарк.

Качество аналитики:

Точность бенчмарков относительно реального рынка (сверка с публичными агрегатами Циан и отчётами консалтинговых агентств).
Стабильность агрегатов во времени (изменчивость от месяца к месяцу при стабильных данных).
Уровень покрытия запросов банков-партнёров (доля запросов, на которые система может дать ответ при текущих правилах обезличивания).

Использование аналитики:

Количество обращений банков-партнёров к API аналитики (по типам запросов).
Количество скоринговых отчётов, сформированных банками-партнёрами на основе бенчмарков Dominium.
Количество выписок для оценщиков в составе их отчётов об оценке.
Количество активных контрактов mortgage_monitoring и analytics_partnership.

Соблюдение правил обезличивания:

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

14. Сценарное моделирование и конструктор¶

Часть A: Предустановленные типы сценариев¶

Сценарий	Параметры	Что пересчитывается
Уход арендатора(ов)	Выбор арендаторов, дата ухода	Vacancy, NOI, DSCR, Cashflow
Изменение ставки	Новая ставка (NET), кому	NOI, средневзвешенная, доходность
Массовая индексация	Формула, дата	Все договоры, NOI, прогноз
Стресс-тест	Vacancy +X%, ставки −Y%, сбор −Z%	NOI, DSCR, LTV, запас прочности
Новый арендатор	Площадь, ставка, каникулы	Vacancy, NOI, средняя ставка
CAPEX-проект	Бюджет, срок, эффект	ROI, NOI-impact, payback
Переоценка стоимости	Новая кадастровая / рыночная стоимость	LTV (3 метода), implied разрыв

Часть B: Конструктор пользовательских сценариев (Sandbox)¶

Доступные параметры для изменения:

Группа	Параметры
Аренда	Ставки (любой/все арендаторы), тип расчёта, каникулы, условия
Арендаторы	Уход, приход новых, изменение площади, смена условий
Vacancy	Целевой %, время экспозиции, зона/этаж
OPEX	Ставка эксплуатации, тарифы, инфляция затрат
CAPEX	Бюджет, сроки, ожидаемый эффект на ставки/vacancy
Индексация	Формула, дата, ИПЦ, курс валюты
Макро	Ключевая ставка, инфляция, рыночная ставка аренды
Налоги	Смена режима, изменение ставки НДС
Кредит	Ставка, рефинансирование, досрочное погашение
Стоимость объекта	Кадастровая, рыночная, Cap Rate для implied

Как работает конструктор¶

Шаг 1: «Создать сценарий» — виртуальная копия текущего состояния
Шаг 2: Выбор параметров и задание новых значений
Шаг 3: Мгновенный пересчёт ВСЕХ зависимых метрик: «Было → Стало → Дельта»
Шаг 4: Сохранение сценария с именем и описанием
Шаг 5: Сравнение до 5 сценариев в одной таблице/графике
Шаг 6: Экспорт в PDF для презентации собственнику/банку

Примеры комбинированных сценариев¶

«Кризис + рефинансирование»: vacancy +20%, ставки −15%, ставка кредита −2% → DSCR?
«Реконцепция этажа»: CAPEX 5 млн + замена арендаторов + ставка +25% → payback?
«Подготовка к продаже»: индексация +10%, vacancy → 5%, CAPEX на фасад → implied стоимость?
«Смена налогового режима»: переход УСН → ОСНО → NET-доходность?
«Падение кадастровой»: кадастровая −15%, рыночная без изменений → LTV-методы

Часть C: LLM-обёртка над конструктором (AI-Native MVP)¶

В дополнение к классическому интерфейсу конструктора (списки параметров, числовые поля) собственник может сформулировать сценарий естественным языком. LLM раскладывает запрос в параметры sandbox и запускает расчёт.

Пример работы:

Запрос собственника: «что будет, если уйдут два крупнейших арендатора и я подниму ставки на 8% для остальных в течение полугода?»
Действие LLM: идентифицирует двух крупнейших арендаторов по доходу, раскладывает в параметры конструктора (Уход арендатора + Изменение ставки + временная шкала), запускает расчёт.
Ответ: пересчитанные NOI, DSCR, vacancy, cashflow + текстовый разбор «что произошло и почему» со ссылками на конкретные договоры.

Принципы работы LLM-обёртки:

Параметры показываются собственнику до запуска расчёта — он может скорректировать перед запуском. Human-in-the-loop.
Результат всегда сопровождается ссылками на исходные данные — какие договоры повлияли, какие метрики изменились, в каком периоде. Объяснимость.
Деградация без AI: при недоступности LLM-провайдера интерфейс возвращается к классическому конструктору с числовыми полями.

См. ADR-009 (AI как архитектурный слой), ADR-010 (выбор LLM-провайдера, открыт).

15. Ролевые интерфейсы¶

Роль	Первый экран и ключевые задачи	Платформа
Собственник	Dashboard портфеля: NOI, доходность, vacancy, implied стоимость. Drill-down. Сценарии. CAPEX. Алерты.	Веб + мобильный
Property Manager	Операционная сводка: просрочки, договоры, заявки, vacancy. Telegram-бот для отчётов.	Веб + мобильный + Telegram
Leasing Manager	Воронка показов с источниками (Авито, ЦИАН, сайт), вакансии, офферы.	Веб
Главный инженер	Заявки, ППР, счётчики. Привязка к плану здания.	Веб + мобильный
Бухгалтер	Начисления (NET+налог), сверки, выгрузка 1С. CSV-импорт банковских выписок.	Веб
Юрист	Договоры, условия, сроки, алерты.	Веб
Акционер	Сводка: выручка, задолженность, заполненность, тренды. PDF-отчёт ежемесячно.	Веб (десктоп/планшет)
Арендатор (ЛК)	Счета (NET+налог=GROSS), задолженность, пени, заявки. Алерт об индексации.	Веб + мобильный

Интерфейс акционера¶

Особенности: - Read-only: только просмотр, никаких действий - Минималистичный: 6–7 KPI на главном экране - PDF-отчёт автоматически 1-го числа каждого месяца на email - Не видит имён арендаторов, деталей договоров - Видит: выручку портфеля, общую задолженность, заполненность, тренд за 12 мес., дополнительные доходы

Интерфейс банка/инвестора¶

Read-only режим со специальными возможностями: - Реалтайм мониторинг залогового актива - Светофор статуса ковенантов - Три метода LTV для разной строгости оценки - График динамики кадастровой стоимости - Возможность оставлять комментарии: «запросить пояснение по метрике X», «отметить риск», «запросить отчёт» - Уведомления по email при срабатывании ключевых триггеров

Telegram-бот для управляющих¶

Ежедневный цикл: - 09:00 — Telegram-сообщение управляющему с inline-кнопками - 09:45 — повтор + SMS fallback (Фаза 2) - 10:00 — алерт руководителю если отчёт не сдан - 10:05 — сводка руководителю (Telegram + email)

Антисаботаж:

Сценарий	Решение
«Забыл»	Telegram 09:00 → повтор 09:45 → SMS → алерт 10:00
«Не работает»	3 канала: Telegram + SMS + веб-форма
«Сложно»	Кнопка «Ничего не произошло» = 1 клик
«Вписал ерунду»	Финансы из системы автоматически. Управляющий вносит только события

5 блоков ежедневного отчёта:

№	Блок	Что вносит
1	Показы	Да/Нет. Помещение, контакт, источник (Авито/ЦИАН/сайт/звонок/сарафан), результат
2	Инциденты	Нет/Да. Описание (текст). Severity. Без фото в MVP
3	Намерения	Без изменений / Съезд / Расширение. Арендатор + комментарий
4	Состояние	В порядке / Проблемы. Помещение + описание
5	Новые договоры	Нет/Да. Арендатор, помещение, площадь, аренда + эксплуатация

AI-копилот (AI-Native MVP):

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

Примеры распознавания:

Текст: «сегодня встречался с арендатором с третьего этажа, просит снижение на 10% иначе уйдёт через полгода» → копилот предлагает Tenant Intention с типом «потенциальный съезд», прикрепляет к договору, обновляет Tenant Health Score, ставит задачу собственнику.
Голосовое: «на парковке прорвало трубу вызвал аварийку» → Incident с severity, статусом, временем, привязкой к юниту.
Текст с показа: «приходила компания из IT смотрели четвёртый этаж контакт +7 интересно готовы вернуться через неделю» → Showing с источником, контактом, результатом.

Принципы:

Подтверждение перед записью. Копилот всегда показывает извлечённую структуру и ждёт от управляющего «Да, так и записать» или «Поправить». Human-in-the-loop.
Деградация без AI. При недоступности LLM-провайдера бот возвращается к классическим формам с кнопками (5 блоков ежедневного отчёта).
Защита персональных данных. Имена и контакты арендаторов, упомянутые в сообщениях, обрабатываются с учётом 152-ФЗ; конкретный механизм маскирования при отправке в облачные API определяется на уровне инференс-слоя (см. ADR-009).

См. ADR-009 (AI как архитектурный слой), ADR-010 (LLM-провайдер).

Интерфейс банка-партнёра¶

Дашборд макро-аналитики для скоринга бизнес-планов потенциальных заёмщиков и оценки сегментов рынка. Ключевые экраны:

Главный экран: интерактивная карта рынка с слоями (ставки, вакансия, платёжная дисциплина) с фильтрами по сегменту, площадной группе, типу объекта.
Сравнение бизнес-плана: ввод параметров заявленного арендного бизнеса (тип, локация, площадь, ставка) → сравнение с медианой и перцентилями сегмента → флаг «реалистично / завышено / занижено».
Сегментная аналитика: глубокое исследование выбранного сегмента (история показателей, распределения, динамика).
API: программный доступ к агрегатам для интеграции в собственные скоринговые модели банка.

Доступ строго read-only. Все запросы логируются. Данные обновляются с учётом opt-out согласий собственников и правил k-anonymity.

Интерфейс банка-кредитора¶

Контекстный мониторинг конкретного залогового актива. Привязан к конкретному заёмщику через активный контракт mortgage_monitoring. Ключевые экраны:

Главный экран по объекту: операционные показатели заёмщика (ставки, заполняемость, NOI, дебиторка, LTV тремя методами) рядом с обезличенным микро-бенчмарком по зданию и макро-бенчмарком по локации. Видно, едет ли актив по рынку.
Алерты: автоматические уведомления при отклонениях (резкий рост вакансии, ухудшение платёжной дисциплины относительно бенчмарка, снижение NOI).
История по объекту: timeline ключевых событий (заключение договоров, индексация, расторжения) с возможностью восстановить картину «что было на дату X».

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

Интерфейс оценщика¶

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

Главный экран по объекту: операционные данные оцениваемого объекта (договоры, ставки, доходность, кадастровая стоимость) и обезличенные бенчмарки по сегменту/локации.
Сравнительный анализ: автоматическое сопоставление параметров объекта с медианой и перцентилями сравнимого сегмента.
Выписка для отчёта: формирование подписанной выписки обезличенных бенчмарков (с датой, хешем состояния данных, версией алгоритма) для включения в отчёт об оценке.

Срок доступа фиксирован контрактом (14-30 дней с возможностью продления). Все действия логируются.

16. Интеграционная карта¶

Система	Направление	Данные	Фаза
1С (Бухгалтерия/ERP)	Двустороннее	Счета, акты, оплаты, сверки, НДС	MVP
CSV-импорт банковских выписок	Входящее	Платежи, разнесение по договорам	MVP
Telegram Bot API	Двустороннее	Ежедневные отчёты управляющих, алерты	MVP
Авито (API/парсинг)	Входящее	Лиды для воронки показов	MVP
ЦИАН (API/парсинг)	Входящее	Лиды для воронки показов	MVP
Email (SMTP)	Исходящее	PDF-отчёты, алерты, уведомления	MVP
Росреестр (pkk.rosreestr.ru)	Входящее	Кадастровая стоимость по кадастровому номеру	Фаза 2 (MVP — ручной ввод)
Банк-клиент	Исходящее	Переход на оплату из ЛК	Фаза 2
ЭДО (Диадок/СБИС)	Двустороннее	УПД, акты, счета-фактуры	Фаза 2
CRM	Опционально	Лиды, контакты, коммуникации	Фаза 2
АСКУЭ	Входящее	Показания счётчиков	Фаза 2
BMS/SCADA	Входящее	Инженерные данные, алерты	Фаза 2
API ЦБ РФ	Входящее	Курсы валют	Фаза 2
Росстат	Входящее	ИПЦ для условной индексации	Фаза 2
ФНС (справочники)	Входящее	Ставки налогов, реквизиты	Фаза 2
DaData / Контур.Фокус	Входящее	Обогащение данных по контрагентам и недвижимости	Фаза 2
SMS-шлюз	Исходящее	SMS fallback для управляющих, алерты арендаторам	Фаза 2
LLM-провайдер (выбор открыт)	Двустороннее	Document AI (PDF → структурированные поля), AI-копилот в Telegram (текст/голос → структурированные сущности), LLM-обёртка сценариев (NL → параметры). См. ADR-010 — конкретный провайдер не зафиксирован, инференс-слой провайдер-агностичен	MVP (AI-Native) + Фаза 2+ (AI-Enhanced)

Принцип: API-first. Каждый модуль через REST API. Обязательные интеграции MVP — 1С, Telegram, Авито, ЦИАН.

17. Технологические принципы и стек¶

15.1 Базовые принципы¶

Cloud-native: Облачное развёртывание, без привязки к географии
Multi-tenant SaaS: Каждый клиент — изолированный тенант
API-first: Все функции через REST API. UI — клиент API
Event-driven: Действия генерируют события. Модули подписываются и реагируют
Расширяемость метрик: Новые KPI через конфигурацию, не код
Версионирование: Договоры, ставки, условия, налоговые режимы, кадастровая стоимость — всё версионируется
Аудит: Каждое действие логируется: кто, когда, что
152-ФЗ compliance: ПДн в РФ. Шифрование. Ролевой доступ
Mobile-ready: Мобильный интерфейс — отдельный оптимизированный клиент
Tax-layer architecture: Бизнес-логика на NET. Налог — подключаемый модуль по юрисдикциям
i18n-ready: Архитектура готова к локализации: языки, валюты, налоговые системы

15.2 Blockchain-ready архитектура¶

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

MVP стратегия: blockchain-ready без blockchain

В MVP blockchain не внедряется напрямую — это добавит сложность без пропорционального эффекта. Вместо этого закладывается blockchain-ready архитектура:

Event Sourcing: все изменения состояния хранятся как неизменяемая последовательность событий (event log)
Хеширование: каждое событие получает SHA-256 хеш, включающий хеш предыдущего события
Неизменяемость: event log не допускает удаления или модификации
Верификация: любая сторона может проверить целостность цепочки событий

Фаза 2: добавить Hyperledger Fabric (private blockchain) для аудита транзакций с ЕГРН и финансовых операций — без изменения бизнес-логики.

15.3 Технологический стек¶

Примечание: окончательный выбор стека зафиксирован отдельным архитектурным решением (см. decisions/ADR-001-tech-stack.md). Здесь приведены требования и ограничения.

Требования к стеку¶

Производительность: real-time dashboards для 1000+ юнитов на объект
Микросервисная архитектура с возможностью независимого деплоя
Поддержка Event Sourcing + CQRS
Blockchain-ready (готовность к интеграции с Hyperledger Fabric в Фазе 2)
Минимальная стоимость инфраструктуры
Доступность специалистов на российском рынке
152-ФЗ compliance (хостинг в РФ)

Ключевые компоненты (предварительный набор)¶

Компонент	Технология	Назначение
Транзакционная БД	PostgreSQL 16+	Договоры, начисления, ЕГРН, юниты, пользователи
Аналитическая БД	ClickHouse	KPI, dashboards, BI, агрегатные запросы
Кэш и сессии	Redis	Real-time уведомления, сессии, кэш
Event Store	PostgreSQL + Kafka	Event sourcing, очереди событий
Файловое хранилище	S3 (Yandex Object Storage)	Документы, сканы, фотографии
Полнотекстовый поиск	Elasticsearch / Meilisearch	Поиск по договорам и арендаторам (Фаза 2)
Frontend (web)	React 18+ TypeScript	Dashboards, формы, таблицы
State management	Zustand / Redux Toolkit	Управление состоянием UI
UI-библиотека	Tailwind + shadcn/ui	Дизайн-система
Таблицы	AG Grid (enterprise)	Сложные таблицы (договоры, дебиторка)
Графики	Apache ECharts / Recharts	KPI dashboards, визуализация
Real-time	WebSocket	Обновление dashboards в реальном времени
Mobile (Фаза 2)	React Native	Кроссплатформенное приложение
Telegram-бот	python-telegram-bot или эквивалент	Ежедневные отчёты управляющих
PDF-генерация	WeasyPrint / Puppeteer	Отчёты для акционера, экспорт сценариев
Cloud	Yandex Cloud (РФ, 152-ФЗ)	Managed PostgreSQL, Redis, Kafka, K8s, S3
Оркестрация	Kubernetes (Yandex Managed K8s)	Контейнеры, auto-scaling
CI/CD	GitLab CI / GitHub Actions	Автоматический build/test/deploy
Мониторинг	Grafana + Prometheus + Loki	Метрики, логи, алерты

Backend язык¶

Финальный выбор языка backend будет зафиксирован архитектурным решением до старта разработки. Кандидаты: Go, Java/Kotlin, Python (FastAPI), Node.js (NestJS). Решение принимается на основе компромисса между производительностью, стоимостью разработки и доступностью специалистов на российском рынке.

Blockchain-стек (Фаза 2)¶

Компонент	Технология	Назначение
Платформа	Hyperledger Fabric 2.x	Private blockchain
Хранение состояния	CouchDB	Smart contract state

18. Дорожная карта, команда и бюджет¶

16.1 Дорожная карта¶

Фаза MVP (9–12 месяцев)¶

Период	Что делается	Результат
Месяц 1–2	Архитектура, ядро данных, двойная иерархия, event sourcing, налоговый модуль, авторизация	Фундамент: объекты, юниты, ЕГРН, налоговые режимы
Месяц 2–4	Contract Engine, timeline условий, жизненный цикл юнита, версионирование. Document AI: первая итерация — извлечение базовых полей из PDF договоров для миграции	Живые договоры, операции с юнитами + автоимпорт существующих договоров
Месяц 4–6	Billing Engine (6 типов), индексация (3 модели), счётчики, пени, налоговый расчёт	Автоначисления, счета NET+налог
Месяц 5–7	Telegram-бот, ManagerReports, Showings, Incidents, TenantIntentions, Alerts. AI-копилот в Telegram: распознавание текста и голоса с подтверждением (протокол изначально проектируется AI-ready)	Ежедневные отчёты управляющих одной фразой или голосом
Месяц 6–8	Dashboards (управляющий, собственник, банк, акционер), Tenant Health Score, дебиторка, ЛК арендатора	Все категории пользователей
Месяц 7–9	Интеграции: 1С, Авито, ЦИАН, банковские выписки CSV. Кадастровая стоимость (ручной ввод + implied)	Внешние системы подключены
Месяц 8–10	Сценарное моделирование + конструктор, Leasing Pipeline. LLM-обёртка над конструктором сценариев: естественный язык → параметры sandbox	What-if + sandbox + NL-интерфейс
Месяц 10–11	CAPEX, бюджетирование, заявки, жизненный цикл владения, PDF-отчёты для акционера	Полный операционный контур
Месяц 11–12	Тестирование, нагрузочные тесты, безопасность, миграция данных, пилот на реальном объекте	MVP в production

Фаза 2 (ещё 9–12 месяцев)¶

Blockchain (Hyperledger Fabric): реестр прав, аудит транзакций
Налоговые пакеты: Казахстан, Узбекистан, ОЭЗ расширенные
Мультивалюта + API ЦБ
Автоподгрузка кадастровой стоимости из Росреестра
ЭДО, CRM расширенная, онлайн-оплата
АСКУЭ, BMS/SCADA
ППР и оборудование, ESG
AI/ML (churn, vacancy, аномалии)
Benchmarking, Due diligence пакет
Нативное мобильное приложение
Монетизация платформы

16.2 Требования к команде разработки¶

Примечание: окончательный состав команды и бюджет будут зафиксированы после финального выбора стека. Цифры ниже — ориентиры. Включение AI-Native компонентов в MVP (Document AI, AI-копилот в Telegram, LLM-обёртка сценариев — см. раздел 6 решение №9 и ADR-009) расширяет состав работ; возможна потребность в роли ML Engineer с месяца 5–6. Точная оценка — после Этапа 1 ТЗ.

Фаза MVP: состав команды¶

Роль	Кол-во	Когда нужен
CTO / Архитектор	1	С месяца 1
Backend Senior	2	С месяца 1
Backend Middle	1	С месяца 3
Frontend Senior	1	С месяца 1
Frontend Middle	1	С месяца 4
UX/UI дизайнер (Senior)	1	С месяца 1
Product Manager	1	С месяца 1
QA Engineer	1	С месяца 3
DevOps / SRE	1	С месяца 1
Аналитик / SA	1	С месяца 1

Итого MVP: 11 человек.

Фаза 2: расширение команды¶

Дополнительная роль	Кол-во
Blockchain-разработчик	1
ML Engineer	1
Mobile-разработчик	1–2
Интеграционный инженер	1
Технический писатель	1

Итого Фаза 2: 14–17 человек.

16.3 Бюджет проекта (предварительная оценка)¶

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

Период	Основные расходы	Ориентировочный бюджет
Фаза MVP (12 мес.)	Разработка с нуля. 11 чел. команда. До production.	70–90 млн руб.
Фаза 2 (12 мес.)	Расширение функционала. 14–17 чел. + blockchain.	115–170 млн руб.
Поддержка Год 1	Стандартная команда + инфраструктура	45–65 млн руб.
ИТОГО (3 года)		230–325 млн руб.

16.4 Облачная инфраструктура¶

Расчёт для Yandex Cloud (основной вариант для 152-ФЗ compliance).

Период	Конфигурация	Итого/мес.	Итого/год
MVP разработка (мес. 1–10)	Dev + Staging	25–40K	250–400K
MVP пилот (мес. 10–12)	Dev + Staging + Prod (старт)	70–110K	~250K (3 мес.)
Год 1 production	Staging + Prod (старт→рост)	80–150K	1.0–1.8 млн
Год 2+ (масштаб)	Staging + Prod (рост) + blockchain node	150–250K	1.8–3.0 млн

16.5 Команда поддержки продукта (после запуска MVP)¶

Конфигурация	Состав	ФОТ с налогами/мес.
Минимальная (1–5 клиентов)	Tech Lead + 1 Backend + 1 Frontend + 0.5 DevOps + 1 Support	2.0–3.0 млн
Стандартная (5–20 клиентов)	+ 1 Backend + 1 QA + 0.5 PM	3.4–4.7 млн
Масштабная (20+ клиентов)	Полная команда 8–10 чел. + L1 support 2–3 чел.	4.7–6.8 млн

16.6 Альтернативные модели снижения бюджета¶

Региональная команда (не Москва): ФОТ × 0.6–0.7 → MVP ~45–60 млн
Смешанная команда (ядро в Москве + разработка в регионе/удалённо): ФОТ × 0.75 → MVP ~55–70 млн
Аутсорсинг части разработки: frontend, мобильное приложение, интеграции
Low-code для ЛК арендатора и простых CRUD-модулей: экономия 10–15% времени frontend

Фазирование аналитического слоя¶

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

MVP (месяцы 8-10):

Запуск Этажа 1 (дескриптивная аналитика).
Базовые метрики (ставки, вакансия, платёжная дисциплина) по основным сегментам.
Доступ собственникам — бесплатно в обмен на данные.
Подключение минимум одного банка-партнёра в пилотном режиме.
Подключение минимум одного банка-кредитора на пилотных условиях.

Фаза 2 (+9-12 месяцев после MVP):

Запуск Этажа 2 (диагностическая аналитика) — объяснение отклонений.
Подключение банков-партнёров на коммерческих условиях (подписка / per-query).
Расширение коммерческой работы с оценщиками.
Запуск блокчейн-слоя для верификации критических агрегатов (хеши в публичный блокчейн).
Полная реализация двухуровневой модели согласия (базовый + расширенный).

Фаза 3 (+12-18 месяцев после Фазы 2):

Запуск Этажа 3 (предиктивная аналитика) — при достижении порога данных (≥100 объектов в региональном сегменте, ≥12 месяцев истории).
Запуск премиум-тарифов на предиктивные модели.
API для внешних финтехов и страховых компаний.
Возможный запуск долевой монетизации для собственников.

Дальняя перспектива:

Этаж 4 (прескриптивная аналитика) — рекомендации действий. Запуск определяется по результатам Этажа 3.

19. Явные не-цели MVP¶

✗ Жилая недвижимость: Не поддерживается
✗ Монетизация платформы: Без модели оплаты в MVP
✗ Мультивалюта: Только рубли. Архитектура готова
✗ Онлайн-оплата: Арендатор видит счёт, платит через свой банк
✗ AI-Enhanced возможности (Этаж 3 ADR-008): predictive Tenant Health Score, vacancy & rate forecasting, anomaly detection в счётчиках и платежах, smart alerts ranking, авто-комментарии для банка-кредитора — открываются при достижении критической массы данных (≥100 объектов в региональном сегменте, ≥12 месяцев истории), не в MVP. AI-Native MVP-компоненты (Document AI, AI-копилот в Telegram, LLM-обёртка сценариев) — в MVP, см. раздел 6 решение №9.
✗ Нативное мобильное: MVP — адаптивный веб
✗ BMS/SCADA: Не подключаются в MVP
✗ ЭДО: Фаза 2
✗ Benchmarking: Фаза 2
✗ Налоги за пределами РФ: Только российские режимы + ОЭЗ. Другие юрисдикции — Фаза 2
✗ Автоподгрузка кадастровой стоимости из Росреестра: В MVP — ручной ввод. API-интеграция — Фаза 2
✗ SMS fallback для управляющих: В MVP — только Telegram + email. SMS — Фаза 2

Не-цели MVP в части аналитического слоя¶

В составе MVP не реализуются:

Этаж 2 аналитики (диагностика отклонений) — фаза 2.
Этаж 3 аналитики (предиктивные модели) — фаза 3 при достижении порога данных.
Этаж 4 аналитики (прескриптивные рекомендации) — дальняя перспектива.
Блокчейн-верификация агрегатов — фаза 2 (архитектура готова, интеграция позже).
Долевая монетизация для собственников — направление развития, не обязательство.
Перепродажа аналитики в b2b-формате (страховые компании, другие финтехи) — фаза 3.
Эксклюзивные партнёрства с банками — модель не предполагает концентрации.

20. Следующий шаг: Этап 1 — Ядро данных и сущности¶

Что будет сделано на Этапе 1:¶

ER-диаграмма ядра: все сущности с атрибутами и связями
Словарь сущностей: каждое поле с типом, обязательностью, допустимыми значениями
Модель версионирования: как хранятся исторические состояния
Модель событий: какие действия генерируют события
Модель прав доступа: матрица «роль × сущность × действие» для всех 11 ролей
Налоговая модель данных: как хранятся и версионируются режимы и юрисдикции
Модель кадастровой стоимости: структура property_valuations, версионирование
Модель ежедневных отчётов: структура manager_reports с 5 блоками

Что нужно от собственника проекта:¶

Подтверждение Этапа 0 v2.0
Примеры реальных договоров (обезличенные) — 3–5 разных типов
Пример счёта с НДС и без — для валидации налогового модуля
Кадастровые номера всех объектов холдинга (для тестирования модуля кадастра)
Окончательное решение по стеку (через ADR-001)
Приоритизация: если нужно сократить MVP — что отложить?

Что нужно от банковского консультанта:¶

Валидация банковских метрик (раздел 13)
Типичные ковенанты российских банков и их пороги
Требования к отчётности банка (формат, периодичность)
Принципы выбора метода LTV в реальной практике
Замечания по dashboard банка (раздел 15)

— КОНЕЦ ЭТАПА 0 v2.0 —

Жду подтверждения и замечаний для перехода к Этапу 1.